From darko at darko.org Mon Apr 1 23:53:37 2013 From: darko at darko.org (Darko) Date: Mon, 1 Apr 2013 14:53:37 -0700 Subject: [M3devel] Why do we need external debugging? Message-ID: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko From dabenavidesd at yahoo.es Tue Apr 2 05:42:39 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 2 Apr 2013 04:42:39 +0100 (BST) Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <1364874159.80556.YahooMailClassic@web172803.mail.ir2.yahoo.com> Hi all: yes, the VAX900 mainframe had this capability, of executing the code an same time verifying its operation results. Would like to make a RT in that way, but it shouldn't be that hard, should be? Thanks in advance PS: BTW I just had an idea today, make the experiment in DEC-SRC of DISPOSABLE memory information safe, so making some adjustments to the type system, with coercion and other soft typing stuff make the language type safe entirely, We would need just suppress the annoying word UNSAFE of all modules, and make the language 100% machine checkable. At the same time introducing functional objects, like in bay Modula-3 , to able to model the language in that way. Thanks in advance --- El lun, 1/4/13, Darko escribi?: De: Darko Asunto: [M3devel] Why do we need external debugging? Para: "m3devel developers" Fecha: lunes, 1 de abril, 2013 16:53 The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Apr 2 06:02:15 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 2 Apr 2013 05:02:15 +0100 (BST) Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1364874159.80556.YahooMailClassic@web172803.mail.ir2.yahoo.com> Message-ID: <1364875335.9036.YahooMailClassic@web172805.mail.ir2.yahoo.com> Hi all: an old known in this list wrote me today precisely about need of source level debuggers and builtin-debuggers in MacApp API in Pascal years: ? http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2013/3/30_Building_Photoshop.html read the last and before last paragraph (sounds like we would need language modification to support this kind of debugger) Thanks in advance --- El lun, 1/4/13, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] Why do we need external debugging? Para: "m3devel developers" , "Darko" Fecha: lunes, 1 de abril, 2013 22:42 Hi all: yes, the VAX900 mainframe had this capability, of executing the code an same time verifying its operation results. Would like to make a RT in that way, but it shouldn't be that hard, should be? Thanks in advance PS: BTW I just had an idea today, make the experiment in DEC-SRC of DISPOSABLE memory information safe, so making some adjustments to the type system, with coercion and other soft typing stuff make the language type safe entirely, We would need just suppress the annoying word UNSAFE of all modules, and make the language 100% machine checkable. At the same time introducing functional objects, like in bay Modula-3 , to able to model the language in that way. Thanks in advance --- El lun, 1/4/13, Darko escribi?: De: Darko Asunto: [M3devel] Why do we need external debugging? Para: "m3devel developers" Fecha: lunes, 1 de abril, 2013 16:53 The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 2 06:22:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Apr 2013 04:22:12 +0000 Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: External debuggers are good. Have you used Visual Studio much? Generate the right debug information and we get excellent working debuggers that people put a lot of time and work into. On the other hand, I do understand your notion of "internal debugger" and agree it is a good approach. - Jay > From: darko at darko.org > Date: Mon, 1 Apr 2013 14:53:37 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Why do we need external debugging? > > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > Am I the only one who thinks this? > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Apr 2 06:44:02 2013 From: darko at darko.org (Darko) Date: Mon, 1 Apr 2013 21:44:02 -0700 Subject: [M3devel] Why do we need external debugging? In-Reply-To: References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: Can't say I like VS, though I have used it. I didn't really use any of the features except the stack dump. For a language like M3 internal debugging makes a lot of sense since it's unlikely to affect anything else, and I like the idea of being able to customize it for my own purposes while maintaining performance. Maybe a simple object based "plug in" architecture would work well. On Apr 1, 2013, at 9:22 PM, Jay K wrote: > External debuggers are good. Have you used Visual Studio much? > Generate the right debug information and we get excellent working debuggers that people put a lot of time and work into. > > > On the other hand, I do understand your notion of "internal debugger" and agree it is a good approach. > > > - Jay > > > > > From: darko at darko.org > > Date: Mon, 1 Apr 2013 14:53:37 -0700 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Why do we need external debugging? > > > > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > > > Am I the only one who thinks this? > > > > - Darko > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 2 15:08:26 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 2 Apr 2013 09:08:26 -0400 Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <20130402130826.GB16617@topoi.pooq.com> On Mon, Apr 01, 2013 at 02:53:37PM -0700, Darko wrote: > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > Am I the only one who thinks this? Internal debuggers are great for programs that are written all in one language. But not so great when multiple languages are involved. Unfortunately, the debuggers we have don't seem to have evolved to exhibit the interfaces needed for source languages significantly different from C. C-- has primitives for stack-walking, on which a debugging-style stack-walker could be built, but even here there's no canonical way to provide variable-name information and the like. -- hendrik From darko at darko.org Tue Apr 2 19:51:48 2013 From: darko at darko.org (Darko) Date: Tue, 2 Apr 2013 10:51:48 -0700 Subject: [M3devel] Internal debugging - a simple design Message-ID: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Here's an idea for how simple internal debugging might work. A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): CONST ProcName: TEXT = "Module.ProcName"; ProcType: CARDINAL = 12345678; ProcAdr: ADDRESS = 123456; ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); ReturnType: CARDINAL = 12345678; ReturnOffs: INTEGER = 32; LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: PROCEDURE DebugProcEntry( READONLY frame: ADDRESS; READONLY procName: ProcName; READONLY procType: ProcType; READONLY procAdr: ProcAdr; READONLY paramNames: ParamNames; READONLY paramTypes: ParamTypes; READONLY paramOffs: ParamOffs; READONLY returnType: ReturnType; READONLY returnOffs: ReturnOffs; READONLY localNames: LocalNames; READONLY localTypes: LocalTypes; READONLY localOffs: LocalOffs ); Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. - Darko From jay.krell at cornell.edu Wed Apr 3 00:39:09 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Apr 2013 22:39:09 +0000 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Message-ID: I don't want to have to recompile anything. Ideally the overhead of the debug stuff is low enough that it is always on. That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. I believe you need to make a function call for every line or "instruction". That is the hook for stepping and breakpoints. You need function calls to the debugger for every assignment. If you have something like "watch breakpoints" ("Break whenv variable x becomes 123.") On the assignment matter though, it could be done in the step/instruction call. There isn't necessarily a zero offset for parameters and locals.. well..a debug system probably creates one..homing all the parameters and not enregistering everything..You should probably bundle up the data into a smaller number of linked structures, in order to pass fewer parameters to DebugProcEntry. Beware module globals also. Even in my upcoming C backend work, they don't work well. I think that needs frontend work. :( - Jay > From: darko at darko.org > Date: Tue, 2 Apr 2013 10:51:48 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Internal debugging - a simple design > > Here's an idea for how simple internal debugging might work. > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > CONST > ProcName: TEXT = "Module.ProcName"; > ProcType: CARDINAL = 12345678; > ProcAdr: ADDRESS = 123456; > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > ReturnType: CARDINAL = 12345678; > ReturnOffs: INTEGER = 32; > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > PROCEDURE DebugProcEntry( > READONLY frame: ADDRESS; > READONLY procName: ProcName; > READONLY procType: ProcType; > READONLY procAdr: ProcAdr; > READONLY paramNames: ParamNames; > READONLY paramTypes: ParamTypes; > READONLY paramOffs: ParamOffs; > READONLY returnType: ReturnType; > READONLY returnOffs: ReturnOffs; > READONLY localNames: LocalNames; > READONLY localTypes: LocalTypes; > READONLY localOffs: LocalOffs > ); > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 3 02:45:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 00:45:23 +0000 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> , <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> Message-ID: > along with a special number for registers and pesudo-functions I missed that, sorry, by skimming. Be sure to use very large but not negative numbers..as negative numbersmight be actual offsets.. > Beware module globals also. > I think they're rare enough that I disagree strongly. I'd really like to fix this too, at least put fields in the "segments" to give backends a chance... Again, though, I don't want to change and recompile anything to debug. Just like normal code. If I'm going to recompile..well, then RTIO.PutText/printf/OutputDebugStringA/DbgPrint like crazy. Sadly, I do a lot of that. Other than an external file, compilers have support for "sections" -- you can put the "cold" code/data "out of the way", but in the same file.There are tradeoffs either way.External files are the way on Windows and increasingly the way on Unix.But then you have to somehow find the file."Internal" is great for ease of finding. Some systems (VMS) keep a minimal amount in the code, and I guess, the rest outside. > Recompile time is quick compared to the overhead this would introduce. The idea is to debug w/o source and compiler.But it is a slippery slope. Full "internal debugging" puts "almost" the source in the executable.Is source absent because it is secret? or large? Or always present? - Jay Subject: Re: [M3devel] Internal debugging - a simple design From: darko at darko.org Date: Tue, 2 Apr 2013 15:54:41 -0700 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On Apr 2, 2013, at 3:39 PM, Jay K wrote:I don't want to have to recompile anything. Ideally the overhead of the debug stuff is low enough that it is always on. That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size. I believe you need to make a function call for every line or "instruction". That is the hook for stepping and breakpoints. I don't think this is required. If you want to break you put in a call in your code. Recompile time is quick compared to the overhead this would introduce. You need function calls to the debugger for every assignment. If you have something like "watch breakpoints" ("Break whenv variable x becomes 123.") On the assignment matter though, it could be done in the step/instruction call. Again, if you want this you put a call in your code, just like the existing pragma. There isn't necessarily a zero offset for parameters and locals.. well..a debug system probably creates one..homing all the parameters and not enregistering everything.. You should probably bundle up the data into a smaller number of linked structures, in order to pass fewer parameters to DebugProcEntry. Notice the offset is an integer, along with a special number for registers and pesudo-functions to access them, wouldn't that avoid changes for debugging? Beware module globals also. Even in my upcoming C backend work, they don't work well. I think that needs frontend work. :( I think they're rare enough that they could be handled with functions instead of this debugging code. - Jay > From: darko at darko.org > Date: Tue, 2 Apr 2013 10:51:48 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Internal debugging - a simple design > > Here's an idea for how simple internal debugging might work. > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > CONST > ProcName: TEXT = "Module.ProcName"; > ProcType: CARDINAL = 12345678; > ProcAdr: ADDRESS = 123456; > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > ReturnType: CARDINAL = 12345678; > ReturnOffs: INTEGER = 32; > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > PROCEDURE DebugProcEntry( > READONLY frame: ADDRESS; > READONLY procName: ProcName; > READONLY procType: ProcType; > READONLY procAdr: ProcAdr; > READONLY paramNames: ParamNames; > READONLY paramTypes: ParamTypes; > READONLY paramOffs: ParamOffs; > READONLY returnType: ReturnType; > READONLY returnOffs: ReturnOffs; > READONLY localNames: LocalNames; > READONLY localTypes: LocalTypes; > READONLY localOffs: LocalOffs > ); > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 3 00:54:41 2013 From: darko at darko.org (Darko) Date: Tue, 2 Apr 2013 15:54:41 -0700 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Message-ID: <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> On Apr 2, 2013, at 3:39 PM, Jay K wrote: > I don't want to have to recompile anything. > Ideally the overhead of the debug stuff is low enough that it is always on. > That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size. > I believe you need to make a function call for every line or "instruction". > That is the hook for stepping and breakpoints. I don't think this is required. If you want to break you put in a call in your code. Recompile time is quick compared to the overhead this would introduce. > You need function calls to the debugger for every assignment. > If you have something like "watch breakpoints" > ("Break whenv variable x becomes 123.") > On the assignment matter though, it could be done in the step/instruction call. Again, if you want this you put a call in your code, just like the existing pragma. > There isn't necessarily a zero offset for parameters and locals.. > well..a debug system probably creates one..homing all the parameters > and not enregistering everything.. > You should probably bundle up the data into a smaller number of linked structures, > in order to pass fewer parameters to DebugProcEntry. Notice the offset is an integer, along with a special number for registers and pesudo-functions to access them, wouldn't that avoid changes for debugging? > > > Beware module globals also. > Even in my upcoming C backend work, they don't work well. > I think that needs frontend work. :( > I think they're rare enough that they could be handled with functions instead of this debugging code. > > - Jay > > > > > > From: darko at darko.org > > Date: Tue, 2 Apr 2013 10:51:48 -0700 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Internal debugging - a simple design > > > > Here's an idea for how simple internal debugging might work. > > > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > > > CONST > > ProcName: TEXT = "Module.ProcName"; > > ProcType: CARDINAL = 12345678; > > ProcAdr: ADDRESS = 123456; > > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > > ReturnType: CARDINAL = 12345678; > > ReturnOffs: INTEGER = 32; > > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > > > PROCEDURE DebugProcEntry( > > READONLY frame: ADDRESS; > > READONLY procName: ProcName; > > READONLY procType: ProcType; > > READONLY procAdr: ProcAdr; > > READONLY paramNames: ParamNames; > > READONLY paramTypes: ParamTypes; > > READONLY paramOffs: ParamOffs; > > READONLY returnType: ReturnType; > > READONLY returnOffs: ReturnOffs; > > READONLY localNames: LocalNames; > > READONLY localTypes: LocalTypes; > > READONLY localOffs: LocalOffs > > ); > > > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > > > - Darko > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 3 04:51:15 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 2 Apr 2013 22:51:15 -0400 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> Message-ID: <20130403025115.GA30084@topoi.pooq.com> On Wed, Apr 03, 2013 at 12:45:23AM +0000, Jay K wrote: > Again, though, I don't want to change and recompile anything to debug. Then an interpreter could be your friend. > The idea is to debug w/o source and compiler.But it is a slippery > slope. Full "internal debugging" puts "almost" the source in the > executable.Is source absent because it is secret? or large? Or always > present? The old Algol W compiler on the IBM 360 could be asked to place a trimmed-down copy of the source code somewhere (in memory if I recall correctly). It would contain bytecodes for reserved words and operators, indexes into a symbol table for identifiers, and the like. Then every time execution would enter a basic block, it would increment a counter -- one counter for each basic block. When execution finished, it would prepare a printout, expanding all those brief byte codes and indices, indenting properly, and printing the count beside the start of every basic block. I would debug from this listing and suppress the usual source-code listing. This count-annotated listing was much more useful. -- hendrik From jay.krell at cornell.edu Wed Apr 3 10:46:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 08:46:10 +0000 Subject: [M3devel] cost of opaque types Message-ID: cost of opaque types fyi: PutI(cstr("Public.F1.a.c"), a.c); PutI == put_adr L_22_L_23 the string L_26_L_27 == a 8 is the "public offset" of c M_Public_L_19 globals for Public.m3 everything else is the computation of the "public base" of a from the base of a actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); simplify slightly (how I wish it got printed...): put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); I still have to track down the whole "recompile again now that offsets are known" path. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 3 15:03:31 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 3 Apr 2013 15:03:31 +0200 Subject: [M3devel] cost of opaque types In-Reply-To: References: Message-ID: <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> There are languages, C# and Java coming to mind? where people accept a lot more from language/compiler for various reasons. :) -- Dragi?a Duri? dragisha at m3w.org On Apr 3, 2013, at 10:46 AM, Jay K wrote: > cost of opaque types > > > fyi: > > PutI(cstr("Public.F1.a.c"), a.c); > > > PutI == put_adr > L_22_L_23 the string > L_26_L_27 == a > 8 is the "public offset" of c > M_Public_L_19 globals for Public.m3 > > > everything else is the computation of the "public base" of a from the base of a > > > actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c > > > put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); > > > simplify slightly (how I wish it got printed...): > > put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); > > > > I still have to track down the whole "recompile again now that offsets are known" path. > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 3 20:53:40 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 03 Apr 2013 11:53:40 -0700 Subject: [M3devel] Why do we need external debugging? In-Reply-To: References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <20130403185340.DC3811A207D@async.async.caltech.edu> All my bigger Modula-3 programs these days include a Scheme interpreter that understands most types in the language... it's not too far from a debugger. Mika Darko writes: > >--Apple-Mail-19-23585903 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=us-ascii > >Can't say I like VS, though I have used it. I didn't really use any of = >the features except the stack dump. For a language like M3 internal = >debugging makes a lot of sense since it's unlikely to affect anything = >else, and I like the idea of being able to customize it for my own = >purposes while maintaining performance. Maybe a simple object based = >"plug in" architecture would work well. > > >On Apr 1, 2013, at 9:22 PM, Jay K wrote: > >> External debuggers are good. Have you used Visual Studio much? >> Generate the right debug information and we get excellent working = >debuggers that people put a lot of time and work into. >>=20 >>=20 >> On the other hand, I do understand your notion of "internal debugger" = >and agree it is a good approach. >>=20 >>=20 >> - Jay >>=20 >>=20 >>=20 >> > From: darko at darko.org >> > Date: Mon, 1 Apr 2013 14:53:37 -0700 >> > To: m3devel at elegosoft.com >> > Subject: [M3devel] Why do we need external debugging? >> >=20 >> > The last time I used an external or lowish-level debugger was the = >last time I programmed in a language other than M3. I find the language = >so safe and reliable that I don't quite understand the need for external = >debuggers. Is it driven by a need to integrate with other languages or = >external libraries? >> >=20 >> > Why can't a debugger be optionally compiled into the code and = >supported by the runtime? I find I don't need much more than the ability = >to log procedure execution, procedure parameters and local variables. I = >imagine some sort of debugging mode with a simple command line and an = >interrupt mechanism would facilitate interactive debugging. >> >=20 >> > Am I the only one who thinks this? >> >=20 >> > - Darko >> >=20 > > >--Apple-Mail-19-23585903 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=us-ascii > >-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Can't = >say I like VS, though I have used it. I didn't really use any of the = >features except the stack dump. For a language like M3 internal = >debugging makes a lot of sense since it's unlikely to affect anything = >else, and I like the idea of being able to customize it for my own = >purposes while maintaining performance. Maybe a simple object based = >"plug in" architecture would work = >well.


On Apr 1, 2013, at 9:22 PM, Jay K = >wrote:

type=3D"cite">separate; font-family: Helvetica; font-style: normal; font-variant: = >normal; font-weight: normal; letter-spacing: normal; line-height: = >normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = >text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
class=3D"hmmessage" style=3D"font-size: 12pt; font-family: Calibri; = >">
External debuggers are good. Have you used Visual = >Studio much?
Generate the right debug information and we get = >excellent working debuggers that people put a lot of time and work = >into.


On the other hand, I do understand your notion of = >"internal debugger" and agree it is a good approach.


 - = >Jay



> = >From: href=3D"mailto:darko at darko.org">darko at darko.org
> Date: Mon, 1 = >Apr 2013 14:53:37 -0700
> To:class=3D"Apple-converted-space"> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = >Subject: [M3devel] Why do we need external debugging?
>class=3D"Apple-converted-space"> 
> The last time I = >used an external or lowish-level debugger was the last time I programmed = >in a language other than M3. I find the language so safe and reliable = >that I don't quite understand the need for external debuggers. Is it = >driven by a need to integrate with other languages or external = >libraries?
>class=3D"Apple-converted-space"> 
> Why can't a = >debugger be optionally compiled into the code and supported by the = >runtime? I find I don't need much more than the ability to log procedure = >execution, procedure parameters and local variables. I imagine some sort = >of debugging mode with a simple command line and an interrupt mechanism = >would facilitate interactive debugging.
>class=3D"Apple-converted-space"> 
> Am I the only one = >who thinks this?
>class=3D"Apple-converted-space"> 
> - = >Darko
>class=3D"Apple-converted-space"> 
= >

= > >--Apple-Mail-19-23585903-- From dragisha at m3w.org Wed Apr 3 23:54:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 3 Apr 2013 23:54:23 +0200 Subject: [M3devel] UTF8, a three zeros library Message-ID: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Zero UNSAFE, zero libc, zero C. https://dl.dropbox.com/u/60554338/UTF8.zip I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8? Suggestions are welcome. And criticism is not unwelcome :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Thu Apr 4 00:26:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 22:26:10 +0000 Subject: [M3devel] cost of opaque types In-Reply-To: <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> References: , <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> Message-ID: If my opaque type exposes no public data, only functions, then I think I'll win significantly by just using "fully transparent prefix object types". I have to check if method calls incur a similar extra overhead. You know, if you have: TYPE T <: OBJECT METHODS F1(); END;NEW(T); vs. interfaceTYPE T = OBJECT METHODS F1(); END; module TYPE TImpl = T OBJECT more stuff END;PROCEDURE CreateT():T = BEGIN RETURN NEW(TImpl); END CreateT; the level of opacity is the same, but the second form likely has much lower overhead. The difference being that you can't directly NEW the type, you have to use a special creator function. Debugging might might might be better in the first case, esp. with stock debuggers, if the backend has or finds enough information (imagine -- backend doesn't really have to be unit-at-a-time..it can sit around building everything in memory..waiting for all the type revelations..and generate everything into one C or .asm or whatever file...) That is, the second case is common in C++ a la COM, and debuggers often only show a vtable and function pointers -- the base type. They ought to figure out from the vtable the leaf type and show everything..maybe Visual Studio does..I use windbg more... - Jay Subject: Re: [M3devel] cost of opaque types From: dragisha at m3w.org Date: Wed, 3 Apr 2013 15:03:31 +0200 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu There are languages, C# and Java coming to mind. where people accept a lot more from language/compiler for various reasons. :) --Dragi?a Duri?dragisha at m3w.org On Apr 3, 2013, at 10:46 AM, Jay K wrote:cost of opaque types fyi: PutI(cstr("Public.F1.a.c"), a.c); PutI == put_adr L_22_L_23 the string L_26_L_27 == a 8 is the "public offset" of c M_Public_L_19 globals for Public.m3 everything else is the computation of the "public base" of a from the base of a actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); simplify slightly (how I wish it got printed...): put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); I still have to track down the whole "recompile again now that offsets are known" path. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 4 00:20:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 22:20:33 +0000 Subject: [M3devel] UTF8, a three zeros library In-Reply-To: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Message-ID: attached my UTF8 library.. clear, simple, Czero libc, zero Modula-3 :) - Jay From: dragisha at m3w.org Date: Wed, 3 Apr 2013 23:54:23 +0200 To: m3devel at elegosoft.com Subject: [M3devel] UTF8, a three zeros library Zero UNSAFE, zero libc, zero C. https://dl.dropbox.com/u/60554338/UTF8.zip I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8. Suggestions are welcome. And criticism is not unwelcome :). --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: utf8.c URL: From dragisha at m3w.org Thu Apr 4 00:28:58 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 4 Apr 2013 00:28:58 +0200 Subject: [M3devel] UTF8, a three zeros library In-Reply-To: References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Message-ID: Great code? maybe a bit short on readability side? :) -- Dragi?a Duri? dragisha at m3w.org On Apr 4, 2013, at 12:20 AM, Jay K wrote: > attached my UTF8 library.. > > clear, simple, C > zero libc, zero Modula-3 :) > > > - Jay > From: dragisha at m3w.org > Date: Wed, 3 Apr 2013 23:54:23 +0200 > To: m3devel at elegosoft.com > Subject: [M3devel] UTF8, a three zeros library > > Zero UNSAFE, zero libc, zero C. > > https://dl.dropbox.com/u/60554338/UTF8.zip > > I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8. > > Suggestions are welcome. And criticism is not unwelcome :). > -- > Dragi?a Duri? > dragisha at m3w.org > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 6 20:40:01 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 6 Apr 2013 20:40:01 +0200 Subject: [M3devel] NARROW(refanyValue, procedureType) Message-ID: Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? new source -> compiling XLModule.m3 "../src/XLModule.m3", line 181: NARROW: types must be assignable "../src/XLModule.m3", line 239: incompatible types (x) Second one is RefSeq.T.addhi(procedureType) TIA, dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mika at async.caltech.edu Sat Apr 6 22:51:45 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 06 Apr 2013 13:51:45 -0700 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: References: Message-ID: <20130406205145.6F2641A207D@async.async.caltech.edu> I think it works as long as you define a (fully specified) wrapper type. e.g., TYPE P = PROCEDURE (x, y : INTEGER) : INTEGER; W = REF RECORD p : P END; ... PROCEDURE Add(x, y : INTEGER) : INTEGER = ... TextWTbl wtbl... wtbl.put("add", NEW(W, p := Add)); ... =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF >Content-Type: multipart/alternative; > boundary="Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4" > > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=utf-8 > >Is this possible in any way? Can I use any Sequence/Table type to hold = >procedure typed values inside? > >new source -> compiling XLModule.m3 >"../src/XLModule.m3", line 181: NARROW: types must be assignable >"../src/XLModule.m3", line 239: incompatible types (x) > >Second one is RefSeq.T.addhi(procedureType) > >TIA, >dd >-- >Dragi=C5=A1a Duri=C4=87 >dragisha at m3w.org > > > > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=utf-8 > >-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Is = >this possible in any way? Can I use any Sequence/Table type to hold = >procedure typed values inside?

new source -> = >compiling XLModule.m3
"../src/XLModule.m3", line 181: NARROW: = >types must be assignable
"../src/XLModule.m3", line 239: = >incompatible types (x)

Second one is = >RefSeq.T.addhi(procedureType)

TIA,
dddiv>
>
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = >Helvetica; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; orphans: 2; = >text-align: -webkit-auto; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; = >">
--
style=3D"font-family: Helvetica; ">Dragi=C5=A1a Duri=C4=87class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: = >normal; font-weight: normal; letter-spacing: normal; line-height: = >normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = >text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = >Helvetica; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; orphans: 2; = >text-align: -webkit-auto; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">

= >

>
>
= > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4-- > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename=signature.asc >Content-Type: application/pgp-signature; > name=signature.asc >Content-Description: Message signed with OpenPGP using GPGMail > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > >iQEcBAEBAgAGBQJRYGwFAAoJEJtljYXUJo8xGvgH/0MAKizqVsumCaf25qcldgcH >PPBGWW5VPRmTEDU2sgRD+1HdkiXwW9Bq5l6Ywv6uIdbZF5SYv64+EAwb9ZCBwIDo >2SxOKZmr0Z4ECl5Jyn6MgZxIOq4sVdHhQ+F5k/1o7C0v7x582A0Td8QnvijoQdRs >LQqQW9ZNYlLDf57dlpCm5+baXem8KO1PNo7Z4If2ceTEaqIb++Ax/Nc8wzEqN1uD >br4GfPKzNmJgQ6RlHbqdoesM4HmbdF2nxMSkVdA8Ydgi5EQH4zBEKFfOsp1uzRjC >VtUkeBwhQyLWNQaaJlR4rzbMDLJprdIyrs9WYQKMALGoYZQiDecy/oH6s8Awgi0= >=tvjq >-----END PGP SIGNATURE----- > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF-- From jay.krell at cornell.edu Sat Apr 6 23:59:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Apr 2013 21:59:26 +0000 Subject: [M3devel] alternate implementation of opaque types? Message-ID: Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? We do suffer from the "fragile base type" problem either way, right? Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. With my proposed change, you can recompile less actually. Though we probably wouldn't bother. As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 01:23:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Apr 2013 23:23:38 +0000 Subject: [M3devel] cm3 should process -D on command line earlier? Message-ID: > cm3 should process -D on command line earlier? I want to be able to say in the config file: if defined("cm3_verbose") M3_FRONT_FLAGS += ["-v"] end if defined("cm3_verbose_version_stamps") M3_FRONT_FLAGS += ["-vsdebug"] end this doesn't quite work because cm3 processes the -D on the command line fairly late -- after it reads "the config file" and before it reads "the m3makefile". (Each of which can and often does include additional files.) I'm working on this change. Alternative a specific flag to cm3 for each frontend flag might be good. I guess verbose is actually already handled. Shall I just "pretend" they are the same? Add frontend flags to cm3 and have cm3 pass them on? i.e. specifically -vsdebug? see /cm3/m3-sys/m3front/src/misc/Host.m3 for possible frontend flags Hm..the thing is, these are mostly meant to be pretty obscure. Often-but-not-always target-specific, set by the config file, and not meant to be user-editable. For example the C backend and NT386 backend have requirements around -inline_nested_procs vs. -unfold_nested_procs. Though really the C backend could easily be made to work either way, esp. at this point that it is many-pass. Reasonable? (I'm specifically wanting -vsdebug to track down what types the C backend is seemingly uninformed about...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 07:56:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 05:56:29 +0000 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? Message-ID: In the C backend, I would like to share code for records and objects. As I understand, objects are always pointers. In my framework, I map typeids to type information. For this to work, given an object, I need to declare both a record and a pointer to it. I need two typeids for that. I'm in the position where I need to compute a typeid. Is that feasible? I have two choices if I can't do that: 1) map from strings instead, where the strings tend to be a string form of a typeid, but where I can make up other forms; quite an inefficiency 1b) have two maps maybe 2) build a flag into my record data that indicates "record or object" #1 is easy but I'm leary of the inefficiency. I'll probably try #2 instead then. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 08:26:46 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 06:26:46 +0000 Subject: [M3devel] m3front/src/types/TypeRep.i3 NO_UID Message-ID: m3front/src/types/TypeRep.i3 NO_UID = -1 is it really guaranteed that a typeid won't end up being -1? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Apr 7 10:03:46 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Apr 2013 10:03:46 +0200 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: Message-ID: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> I second this. I never had problems with these instances of "over-compilation". Why bother, and why introduce possible problems down the road by fixing what is not broken? -- Dragi?a Duri? dragisha at m3w.org On Apr 6, 2013, at 11:59 PM, Jay K wrote: > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 7 13:09:51 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Apr 2013 21:09:51 +1000 Subject: [M3devel] m3front/src/types/TypeRep.i3 NO_UID In-Reply-To: References: Message-ID: Yes. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Apr 7, 2013, at 4:26 PM, Jay K wrote: > m3front/src/types/TypeRep.i3 NO_UID = -1 > is it really guaranteed that a typeid won't end up being -1? > > > Thanks, > - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 7 13:10:03 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Apr 2013 21:10:03 +1000 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> References: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> Message-ID: <5618C4A4-E9AB-460F-BAF6-D59B0623DDA4@cs.purdue.edu> There can be multiple levels of opacity. So I don?t see how you would do this. On Apr 7, 2013, at 6:03 PM, Dragi?a Duri? wrote: > I second this. I never had problems with these instances of "over-compilation". Why bother, and why introduce possible problems down the road by fixing what is not broken? > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 6, 2013, at 11:59 PM, Jay K wrote: > >> With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 7 17:48:57 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 10:48:57 -0500 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: Message-ID: <51619569.4070202@lcwb.coop> On 04/06/2013 04:59 PM, Jay K wrote: > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > This is neither an implementation nor a language design question, but a programmer's option. The language allows private things before or after public, or more complicated combinations, e.g., private, public, private. In fact, arbitrary combinations are possible, although how to put them together gets tricky and requires a lot of separate compilations. Here is a public-private-public example that is, I think, believable: INTERFACE Stack ; TYPE T <: Public ; TYPE Public = OBJECT METHODS push ( I : INTEGER ) ... END (* Public *) ; END Stack . (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) Later, somebody else wants to add: INTERFACE StackWithStats ; IMPORT Stack ; TYPE T = Stack . T OBJECT PushCt : CARDINAL := 0 ... OVERRIDES push := Push ... END (* T *) ; PROCEDURE Push ( s : T ; I : INTEGER ) ; END StackWithStats . MODULE StackWithStats ; PROCEDURE Push ( s : T ; I : INTEGER ) = BEGIN INC ( s . PushCt ) ; Stack . T . push ( s , I ) END Push ... ; BEGIN END StackWithStats . > > We do suffer from the "fragile base type" problem either way, right? > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > - Jay From rodney_bates at lcwb.coop Sun Apr 7 18:02:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 11:02:51 -0500 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: References: Message-ID: <516198AB.5040509@lcwb.coop> On 04/07/2013 12:56 AM, Jay K wrote: > In the C backend, I would like to share code for records and objects. > > > As I understand, objects are always pointers. Yes. > > > In my framework, I map typeids to type information. > > > For this to work, given an object, I need to declare both a record > and a pointer to it. I need two typeids for that. > > > I'm in the position where I need to compute a typeid. > Is that feasible? > > > > I have two choices if I can't do that: > > > 1) map from strings instead, where the strings tend to be > a string form of a typeid, but where I can make up other forms; > quite an inefficiency > > > 1b) have two maps maybe > > > > 2) build a flag into my record data that indicates "record or object" FWIW, I believe it is true that every way of using an object type in Modula-3 implicitly and uniquely identifies whether it works on the pointer or the heap object. For example, := and = mean the pointer, while any use of . implies dereferencing. There is no whole-object assignment or whole-object comparison, as there are for REF RECORD (which has two types). Maybe this distinction is lost in the lowering that happens by the time M3C gets it, or later. > > > #1 is easy but I'm leary of the inefficiency. > I'll probably try #2 instead then. > > > > - Jay > > From rodney_bates at lcwb.coop Sun Apr 7 18:21:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 11:21:40 -0500 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: References: Message-ID: <51619D14.6070903@lcwb.coop> On 04/06/2013 01:40 PM, Dragi?a Duri? wrote: > Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? > > new source -> compiling XLModule.m3 > "../src/XLModule.m3", line 181: NARROW: types must be assignable > "../src/XLModule.m3", line 239: incompatible types (x) > From 2.2.10: NULL <: REF T <: REFANY and similarly, any object type <: ROOT <: REFANY but while NULL <: PROCEDURE... NOT PROCEDURE... <: REFANY nor PROCEDURE... <: ADDRESS Which is why you can't assign a procedure value to a pointer of any kind, nor can you narrow a pointer back to a procedure. Changing the language to allow this would, I think, entail significant implementation complexity. Do you want all of the procedure values in the sequence to be the same procedure type? If so, you should be able to just instantiate Sequence using an interface containing a T that is this procedure type. No runtime NARROW overhead, and more static checking. Otherwise, Mika's wrapping example should be extensible by having a different wrapper type around each needed procedure type. Then they could be mixed and matched in a single sequence. > Second one is RefSeq.T.addhi(procedureType) > > TIA, > dd > -- > Dragi?a Duri? > dragisha at m3w.org > > > From dragisha at m3w.org Sun Apr 7 18:47:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Apr 2013 18:47:15 +0200 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: <51619D14.6070903@lcwb.coop> References: <51619D14.6070903@lcwb.coop> Message-ID: <4A99AADA-503C-4BA9-9FAA-9133796EA851@m3w.org> Mika's idea is exactly what I needed. I was cleaning some old code and ARRAY's of fixed size "emulating" collections are one my favourite targets :). More than enough, and more than powerful enough, this mechanism is. -- Dragi?a Duri? dragisha at m3w.org On Apr 7, 2013, at 6:21 PM, Rodney M. Bates wrote: > Do you want all of the procedure values in the sequence to be the same > procedure type? If so, you should be able to just instantiate Sequence > using an interface containing a T that is this procedure type. No > runtime NARROW overhead, and more static checking. > > Otherwise, Mika's wrapping example should be extensible by having a different > wrapper type around each needed procedure type. Then they could be mixed and > matched in a single sequence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 7 19:23:59 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 07 Apr 2013 10:23:59 -0700 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: <51619D14.6070903@lcwb.coop> References: <51619D14.6070903@lcwb.coop> Message-ID: <20130407172359.7DD2E1A207D@async.async.caltech.edu> I should add that m3tk could be used to generate such procedure type wrappers automatically. It's one of the things I never got around to in my Scheme system (since you can usually just use OBJECTs anyhow, at least if you control the source code), but it shouldn't be too difficult... Mika "Rodney M. Bates" writes: > > >On 04/06/2013 01:40 PM, Dragi??a Duri?? wrote: >> Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? >> >> new source -> compiling XLModule.m3 >> "../src/XLModule.m3", line 181: NARROW: types must be assignable >> "../src/XLModule.m3", line 239: incompatible types (x) >> > > From 2.2.10: > >NULL <: REF T <: REFANY >and similarly, any object type <: ROOT <: REFANY > >but while NULL <: PROCEDURE... >NOT PROCEDURE... <: REFANY nor PROCEDURE... <: ADDRESS > >Which is why you can't assign a procedure value to a pointer of any kind, nor >can you narrow a pointer back to a procedure. Changing the language to allow >this would, I think, entail significant implementation complexity. > >Do you want all of the procedure values in the sequence to be the same >procedure type? If so, you should be able to just instantiate Sequence >using an interface containing a T that is this procedure type. No >runtime NARROW overhead, and more static checking. > >Otherwise, Mika's wrapping example should be extensible by having a different >wrapper type around each needed procedure type. Then they could be mixed and >matched in a single sequence. > >> Second one is RefSeq.T.addhi(procedureType) >> >> TIA, >> dd >> -- >> Dragi??a Duri?? >> dragisha at m3w.org >> >> >> From hendrik at topoi.pooq.com Sun Apr 7 20:37:46 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Apr 2013 14:37:46 -0400 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: <516198AB.5040509@lcwb.coop> References: <516198AB.5040509@lcwb.coop> Message-ID: <20130407183746.GB24973@topoi.pooq.com> On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote: > > > On 04/07/2013 12:56 AM, Jay K wrote: > >In the C backend, I would like to share code for records and objects. > > > > > >As I understand, objects are always pointers. > > Yes. > > > > > > >In my framework, I map typeids to type information. > > > > > >For this to work, given an object, I need to declare both a record > >and a pointer to it. I need two typeids for that. > > > > > >I'm in the position where I need to compute a typeid. > >Is that feasible? > > > > > > > >I have two choices if I can't do that: > > > > > > 1) map from strings instead, where the strings tend to be > > a string form of a typeid, but where I can make up other forms; > > quite an inefficiency > > > > > > 1b) have two maps maybe > > > > > > > > 2) build a flag into my record data that indicates "record or object" > > FWIW, I believe it is true that every way of using an object type in Modula-3 > implicitly and uniquely identifies whether it works on the pointer or the > heap object. For example, := and = mean the pointer, while any use of . implies > dereferencing. There is no whole-object assignment or whole-object comparison, > as there are for REF RECORD (which has two types). > > Maybe this distinction is lost in the lowering that happens by the time M3C gets it, > or later. I this matter Modula 3 is very different from C++, which idenntifies classes wiith structure types. It even treats struct and class as equivalent keywords. That was a big mistake in C++, and results in pathological behavior when assigning class values instead of class pointers. -- hendrik k From jay.krell at cornell.edu Sun Apr 7 21:07:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 19:07:15 +0000 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: <51619569.4070202@lcwb.coop> References: , <51619569.4070202@lcwb.coop> Message-ID: My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > The language allows private things before or after public, or more complicated combinations, I didn't realize. - Jay > Date: Sun, 7 Apr 2013 10:48:57 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > This is neither an implementation nor a language design question, but a programmer's option. > The language allows private things before or after public, or more complicated combinations, > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > to put them together gets tricky and requires a lot of separate compilations. > > Here is a public-private-public example that is, I think, believable: > > INTERFACE Stack > ; TYPE T <: Public > ; TYPE Public = OBJECT METHODS > push ( I : INTEGER ) > ... > END (* Public *) > ; END Stack . > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > Later, somebody else wants to add: > > INTERFACE StackWithStats > ; IMPORT Stack > ; TYPE T = Stack . T OBJECT > PushCt : CARDINAL := 0 > ... > OVERRIDES > push := Push > ... > END (* T *) > ; PROCEDURE Push ( s : T ; I : INTEGER ) > ; END StackWithStats . > > MODULE StackWithStats > ; PROCEDURE Push ( s : T ; I : INTEGER ) > = BEGIN > INC ( s . PushCt ) > ; Stack . T . push ( s , I ) > END Push > ... > ; BEGIN END StackWithStats . > > > > > We do suffer from the "fragile base type" problem either way, right? > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 21:16:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 19:16:41 +0000 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: <20130407183746.GB24973@topoi.pooq.com> References: , <516198AB.5040509@lcwb.coop>, <20130407183746.GB24973@topoi.pooq.com> Message-ID: I figured out a way that probably works. I use -1 for the typeid of the made up record, and hope that I don't need it. What C++ does makes a lot of sense actually. What you are missing is that "classes" or "types" have different use-cases. More than 2. Stroustrup identifies a few. Off the top of my head, though: 1) value types like std::string Here the value semantics are what you want. This also includes container classes like std::vector, std::queue, etc., that you don't often want to assign, but when you do, they offer a good way to do it. 2) typical "object oriented stuff" like "Window" with virtual functions that get overridden 3) "object oriented stuff" w/ plugins like how Modula-3 Rd/Wr work and how C++ iostreams work -- you plugin a "buffer". You always call "toplevel" non-overridden functions that selectively call more derived overrides. The toplevel provides a "framework" and common code is lifted out of the derived types, leaving them only to implement "what varies". I think actually in general #2 is overrused and #3 is kind of better. #1 is different and appropriately often used. 4) Sometimes just for scoping globals, i.e. "singleton" / "manager" classes. The way you enforce stuff is that types that aren't meant to be assigned should have abstract functions, so you can't instantiate them directly. And then, also, you wrap up #2/#3 in #1 -- std::unique_ptr / std::shared_ptr and such. Modula-3 favors only #2 or #3. Many languages don't have good support for #1 really. You know -- Modula-3 TEXT and java String get special treatment by the compiler and w/o compiler support, nobody can implement anything quite like them, whereas C++ std::string is implemented with powers available to anyone. Anyway, I think I solved my problem. Aside from opaque types always being "ADDRESS", I have good typeinfo in the C backend now. Also exluding global variables, which remain awful. Now to start using these types for locals/parameters... - Jay > Date: Sun, 7 Apr 2013 14:37:46 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] computing a typeid in backend for a pointer to a declared type?? > > On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote: > > > > > > On 04/07/2013 12:56 AM, Jay K wrote: > > >In the C backend, I would like to share code for records and objects. > > > > > > > > >As I understand, objects are always pointers. > > > > Yes. > > > > > > > > > > >In my framework, I map typeids to type information. > > > > > > > > >For this to work, given an object, I need to declare both a record > > >and a pointer to it. I need two typeids for that. > > > > > > > > >I'm in the position where I need to compute a typeid. > > >Is that feasible? > > > > > > > > > > > >I have two choices if I can't do that: > > > > > > > > > 1) map from strings instead, where the strings tend to be > > > a string form of a typeid, but where I can make up other forms; > > > quite an inefficiency > > > > > > > > > 1b) have two maps maybe > > > > > > > > > > > > 2) build a flag into my record data that indicates "record or object" > > > > FWIW, I believe it is true that every way of using an object type in Modula-3 > > implicitly and uniquely identifies whether it works on the pointer or the > > heap object. For example, := and = mean the pointer, while any use of . implies > > dereferencing. There is no whole-object assignment or whole-object comparison, > > as there are for REF RECORD (which has two types). > > > > Maybe this distinction is lost in the lowering that happens by the time M3C gets it, > > or later. > > I this matter Modula 3 is very different from C++, which idenntifies > classes wiith structure types. It even treats struct and class as > equivalent keywords. That was a big mistake in C++, and > results in pathological behavior when assigning class > values instead of class pointers. > > -- hendrik > k -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Mon Apr 8 12:37:46 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Mon, 8 Apr 2013 12:37:46 +0200 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: , <51619569.4070202@lcwb.coop> Message-ID: If M3 would merge interfaces and modules, like Oberon and golang have done, with the addition of selective export (hidden, readonly, public) of record/object fields and mixins (aka called "interfaces" in Java and C#), it wouldn't need the extra complications of opaque types at all. From: Jay K Sent: Sunday, April 07, 2013 9:07 PM To: Rodney M. Bates ; m3devel Subject: Re: [M3devel] alternate implementation of opaque types? My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > The language allows private things before or after public, or more complicated combinations, I didn't realize. - Jay > Date: Sun, 7 Apr 2013 10:48:57 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > This is neither an implementation nor a language design question, but a programmer's option. > The language allows private things before or after public, or more complicated combinations, > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > to put them together gets tricky and requires a lot of separate compilations. > > Here is a public-private-public example that is, I think, believable: > > INTERFACE Stack > ; TYPE T <: Public > ; TYPE Public = OBJECT METHODS > push ( I : INTEGER ) > ... > END (* Public *) > ; END Stack . > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > Later, somebody else wants to add: > > INTERFACE StackWithStats > ; IMPORT Stack > ; TYPE T = Stack . T OBJECT > PushCt : CARDINAL := 0 > ... > OVERRIDES > push := Push > ... > END (* T *) > ; PROCEDURE Push ( s : T ; I : INTEGER ) > ; END StackWithStats . > > MODULE StackWithStats > ; PROCEDURE Push ( s : T ; I : INTEGER ) > = BEGIN > INC ( s . PushCt ) > ; Stack . T . push ( s , I ) > END Push > ... > ; BEGIN END StackWithStats . > > > > > We do suffer from the "fragile base type" problem either way, right? > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 8 18:08:08 2013 From: jay.krell at cornell.edu (Jay) Date: Mon, 8 Apr 2013 09:08:08 -0700 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: <51619569.4070202@lcwb.coop> Message-ID: I agree COM/Java/C# interfaces are very good for structuring large systems, maintaining opacity, and are reasonably simple and efficient. They preclude direct access to public data, for better and worse. They are achievable in Modula-3, like in C, tediously and you invent your own idiom (a separate object, with back pointer to the "real" one, and small functions to forward to it.) I don't know what Oberon/golang do here. - Jay On Apr 8, 2013, at 3:37 AM, Dirk Muysers wrote: > If M3 would merge interfaces and modules, like Oberon and golang > have done, with the addition of selective export (hidden, readonly, public) > of record/object fields and mixins (aka called "interfaces" in Java and C#), > it wouldn't need the extra complications of opaque types at all. > > From: Jay K > Sent: Sunday, April 07, 2013 9:07 PM > To: Rodney M. Bates ; m3devel > Subject: Re: [M3devel] alternate implementation of opaque types? > > My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. > > > If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > > > > The language allows private things before or after public, or more complicated combinations, > > > I didn't realize. > > > - Jay > > > > Date: Sun, 7 Apr 2013 10:48:57 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > > > > This is neither an implementation nor a language design question, but a programmer's option. > > The language allows private things before or after public, or more complicated combinations, > > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > > to put them together gets tricky and requires a lot of separate compilations. > > > > Here is a public-private-public example that is, I think, believable: > > > > INTERFACE Stack > > ; TYPE T <: Public > > ; TYPE Public = OBJECT METHODS > > push ( I : INTEGER ) > > ... > > END (* Public *) > > ; END Stack . > > > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > > > Later, somebody else wants to add: > > > > INTERFACE StackWithStats > > ; IMPORT Stack > > ; TYPE T = Stack . T OBJECT > > PushCt : CARDINAL := 0 > > ... > > OVERRIDES > > push := Push > > ... > > END (* T *) > > ; PROCEDURE Push ( s : T ; I : INTEGER ) > > ; END StackWithStats . > > > > MODULE StackWithStats > > ; PROCEDURE Push ( s : T ; I : INTEGER ) > > = BEGIN > > INC ( s . PushCt ) > > ; Stack . T . push ( s , I ) > > END Push > > ... > > ; BEGIN END StackWithStats . > > > > > > > > We do suffer from the "fragile base type" problem either way, right? > > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 8 21:06:24 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Apr 2013 19:06:24 +0000 Subject: [M3devel] dbxout.c commit In-Reply-To: <20130408183918.555525DEA9D@birch.elegosoft.com> References: <20130408183918.555525DEA9D@birch.elegosoft.com> Message-ID: Note that this file is pretty dead. see cm3/m3-sys/m3cc/gcc-4.5/gcc/dbxout.c cm3/m3-sys/m3cc/gcc-4.6/gcc/dbxout.c cm3/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c cm3/m3-sys/m3cc/src/m3makefile As I recall: 4.5 was in use a while, maybe in the previous release? 4.6 I don't think was in use much, and contains the heavier handed optimizer removal by me most systems are using 4.7, but it hasn't been for long The "unversioned" directory is 4.3. We never imported 4.4. - Jay > Date: Mon, 8 Apr 2013 20:39:18 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/04/08 20:39:18 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c > > Log message: > Some end-of-function comments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 9 17:52:04 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 09 Apr 2013 10:52:04 -0500 Subject: [M3devel] dbxout.c commit In-Reply-To: References: <20130408183918.555525DEA9D@birch.elegosoft.com> Message-ID: <51643924.603@lcwb.coop> Yeah, I've realized for a while I have more work than adding trivial comments, for these three new gcc backends. On 04/08/2013 02:06 PM, Jay K wrote: > Note that this file is pretty dead. > > see > cm3/m3-sys/m3cc/gcc-4.5/gcc/dbxout.c > cm3/m3-sys/m3cc/gcc-4.6/gcc/dbxout.c > cm3/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c > cm3/m3-sys/m3cc/src/m3makefile > > As I recall: > 4.5 was in use a while, maybe in the previous release? > 4.6 I don't think was in use much, and contains the heavier handed optimizer removal by me > most systems are using 4.7, but it hasn't been for long > The "unversioned" directory is 4.3. > We never imported 4.4. > > > - Jay > > > Date: Mon, 8 Apr 2013 20:39:18 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/04/08 20:39:18 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c > > > > Log message: > > Some end-of-function comments. > > From jay.krell at cornell.edu Wed Apr 10 04:12:52 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Apr 2013 02:12:52 +0000 Subject: [M3devel] typenames vs. typeids in M3CG? Message-ID: Given something like: TYPE A = RECORD ... END; (* typeid 123456 *) TYPE B = A; VAR a:A; VAR b:B; ideally the generated code looks like: struct T123456; typedef struct T123456 T123456; struct T123456 { ... }; typedef T123456 A; typedef T123456 B; A a; B b; Currently I produce: T123456 a; T123456 b; it is easy to make the first or better yet last typename for any given typeid win, giving us: B a; B b; However actually producing the ideal/idiomatic: A a; B b; I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. Reasonable? The problem seems worst for records. But it applies to enums, subranges, opaque types. Actual source is full of typenames. M3CG is full of typeids. TYPE Color = {Red, Blue, Green}; The thing to the right is anonymous type with a typeid (structural hash). TYPE Color2 = {Red, Blue, Green}; VAR Color:c; VAR Color2:c2; In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ Color c; Color2 c2; However, again, without frontend help we are faced with probably: T1234 c; T1234 c2; or perhaps Color c; Color2 c2; Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. Similarly for opaque types, currently I have: typdef char* ADDRESS; TYPE A <: whatever; TYPE B <: whatever; typedef ADDRESS T1234; (* typeid for opaque type *) typedef ADDRESS T123478; (* typeid for opaque type *) T1234 a; T123478 b; This is not particularly readable. It can go either way: ADDRESS a; ADDRESS b; Or ideally more like: A* a; B* b; or A a; B b; Opaque types are a larger problem, at least in my head. I'd like to have pointers to structs, but I don't yet know how to make that work. Either the public part or the entire thing. If the information is available. The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) If you have used stock gdb or debugged the NT386 target, you should realize the problem. I believe the frontend should be passing typenames along with typeids for locals/parameters. I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. Advise? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 10 05:43:26 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Apr 2013 13:43:26 +1000 Subject: [M3devel] typenames vs. typeids in M3CG? In-Reply-To: References: Message-ID: <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> I actually prefer the declarations T123456 a; T123456 b; Type names mean nothing in Modula-3?s structural type system. On Apr 10, 2013, at 12:12 PM, Jay K wrote: > Given something like: > > > TYPE A = RECORD ... END; (* typeid 123456 *) > TYPE B = A; > > > VAR a:A; > VAR b:B; > > > > ideally the generated code looks like: > > > struct T123456; typedef struct T123456 T123456; > struct T123456 { ... }; > > > typedef T123456 A; > typedef T123456 B; > A a; > B b; > > Currently I produce: > T123456 a; > T123456 b; > > it is easy to make the first or better yet last typename for any given typeid win, giving us: > B a; > B b; > > However actually producing the ideal/idiomatic: > A a; > B b; > > I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. > Reasonable? > > > The problem seems worst for records. > But it applies to enums, subranges, opaque types. > > > Actual source is full of typenames. M3CG is full of typeids. > > > TYPE Color = {Red, Blue, Green}; > > > The thing to the right is anonymous type with a typeid (structural hash). > > > TYPE Color2 = {Red, Blue, Green}; > > VAR Color:c; > VAR Color2:c2; > > > In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: > > typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ > > > Color c; > Color2 c2; > > > However, again, without frontend help we are faced with probably: > T1234 c; > T1234 c2; > > or perhaps > Color c; > Color2 c2; > > > Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. > That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. > > > Similarly for opaque types, currently I have: > > > typdef char* ADDRESS; > TYPE A <: whatever; > TYPE B <: whatever; > > > typedef ADDRESS T1234; (* typeid for opaque type *) > typedef ADDRESS T123478; (* typeid for opaque type *) > > > T1234 a; > T123478 b; > > > This is not particularly readable. > It can go either way: > ADDRESS a; > ADDRESS b; > > > Or ideally more like: > A* a; > B* b; > > > or > A a; > B b; > > > Opaque types are a larger problem, at least in my head. > I'd like to have pointers to structs, but I don't yet know how to make that work. > Either the public part or the entire thing. If the information is available. > > > The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. > (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) > > > If you have used stock gdb or debugged the NT386 target, you should realize the problem. > > > I believe the frontend should be passing typenames along with typeids for locals/parameters. > I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. > Advise? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 10 17:14:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Apr 2013 15:14:27 +0000 Subject: [M3devel] typenames vs. typeids in M3CG? In-Reply-To: <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> References: , <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> Message-ID: In the debugger and, I somewhat lied, for the C to somewhat mimic the Modula-3, I'd definitely prefer "A" and "B". C++ programmers wrestle with this, but it is widely agreed to be a "quality bug" (correct but not ideal) and ought to be fixed. If I say: std::string a; and hover over it in a debugger, I see something ridiculous std::basic_string<...something really long>. The (Microsoft, at least) compiler was fixed to issue warnings in terms of "used types" instead of "alias bases", but the debuginfo was not. Enums are likely to end up like: enum T1234 { T1234_Red, T1234_Blue, T1234_Green }; anything given just one typename I have a chance of "fixing" well. But in the face of multiple typenames, an arbitrary one will win. I can go back and replace the text T1234 with "Color" or or "Color_" whatnot..even in the enum members. - Jay From: hosking at cs.purdue.edu Date: Wed, 10 Apr 2013 13:43:26 +1000 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] typenames vs. typeids in M3CG? I actually prefer the declarations T123456 a;T123456 b; Type names mean nothing in Modula-3?s structural type system. On Apr 10, 2013, at 12:12 PM, Jay K wrote:Given something like: TYPE A = RECORD ... END; (* typeid 123456 *) TYPE B = A; VAR a:A; VAR b:B; ideally the generated code looks like: struct T123456; typedef struct T123456 T123456; struct T123456 { ... }; typedef T123456 A; typedef T123456 B; A a; B b; Currently I produce: T123456 a; T123456 b; it is easy to make the first or better yet last typename for any given typeid win, giving us: B a; B b; However actually producing the ideal/idiomatic: A a; B b; I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. Reasonable? The problem seems worst for records. But it applies to enums, subranges, opaque types. Actual source is full of typenames. M3CG is full of typeids. TYPE Color = {Red, Blue, Green}; The thing to the right is anonymous type with a typeid (structural hash). TYPE Color2 = {Red, Blue, Green}; VAR Color:c; VAR Color2:c2; In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ Color c; Color2 c2; However, again, without frontend help we are faced with probably: T1234 c; T1234 c2; or perhaps Color c; Color2 c2; Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. Similarly for opaque types, currently I have: typdef char* ADDRESS; TYPE A <: whatever; TYPE B <: whatever; typedef ADDRESS T1234; (* typeid for opaque type *) typedef ADDRESS T123478; (* typeid for opaque type *) T1234 a; T123478 b; This is not particularly readable. It can go either way: ADDRESS a; ADDRESS b; Or ideally more like: A* a; B* b; or A a; B b; Opaque types are a larger problem, at least in my head. I'd like to have pointers to structs, but I don't yet know how to make that work. Either the public part or the entire thing. If the information is available. The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) If you have used stock gdb or debugged the NT386 target, you should realize the problem. I believe the frontend should be passing typenames along with typeids for locals/parameters. I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. Advise? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 07:14:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 05:14:10 +0000 Subject: [M3devel] 32bit negative base 16 constants? Message-ID: I have some 32bit constants. e.g.: CONST UID_WORD = 16_97E237E2; but this isn't right. On a 64bit system, that is a 64bit integer with a "large" positive value, instead of the intended 32bit negative value. Is there an ideal (i.e. CONST) way to do this? Portably to 64bit systems? I have found two unsatisfactory choices: 1) use decimal: #include int main() { printf("%X %d\n", 0x97E237E2); return 0; } cc 1.c ./a.out 97E237E2 -1881139893 CONST UID_WORD = (* 16_97E237E2 *) -1881139893; 2) change it to VAR and a runtime conversion: PROCEDURE SignExtend(a, b: INTEGER): INTEGER = BEGIN b := Word.LeftShift(-1, b - 1); IF Word.And(a, b) # 0 THEN a := Word.Or(a, b); END; RETURN a; END SignExtend; PROCEDURE SignExtend32(a: INTEGER): INT32 = BEGIN RETURN SignExtend(a, 32); END SignExtend32; CONST IntegerToTypeid = SignExtend32; VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) This gives a warning: CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) and then at runtime gives an error assigning it to an INT32. any other ways? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 11 08:03:02 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Apr 2013 16:03:02 +1000 Subject: [M3devel] 32bit negative base 16 constants? In-Reply-To: References: Message-ID: <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> Actually, writing that you get what you expressed: If an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation uses the convention of the Word interface. Word.T is unsigned, so you only get the 32 bits you asked for. If you want a signed value then you need to express the sign explicitly starting from a constant, just as you have done with: > CONST UID_WORD = (* 16_97E237E2 *) -1881139893; On Apr 11, 2013, at 3:14 PM, Jay K wrote: > > I have some 32bit constants. > > e.g.: > > CONST UID_WORD = 16_97E237E2; > > but this isn't right. > On a 64bit system, that is a 64bit integer > with a "large" positive value, instead of > the intended 32bit negative value. > > Is there an ideal (i.e. CONST) way to do this? > Portably to 64bit systems? > > I have found two unsatisfactory choices: > > 1) use decimal: > > #include > int main() > { > printf("%X %d\n", 0x97E237E2); > return 0; > } > > > cc 1.c > ./a.out > 97E237E2 -1881139893 > > CONST UID_WORD = (* 16_97E237E2 *) -1881139893; > > > 2) change it to VAR and a runtime conversion: > > > PROCEDURE SignExtend(a, b: INTEGER): INTEGER = > BEGIN > b := Word.LeftShift(-1, b - 1); > IF Word.And(a, b) # 0 THEN > a := Word.Or(a, b); > END; > RETURN a; > END SignExtend; > > PROCEDURE SignExtend32(a: INTEGER): INT32 = > BEGIN > RETURN SignExtend(a, 32); > END SignExtend32; > > CONST IntegerToTypeid = SignExtend32; > > > VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) > > This gives a warning: > > CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) > > and then at runtime gives an error assigning it to an INT32. > > > any other ways? > > > Thanks, > - Jay > > Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 08:17:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 06:17:51 +0000 Subject: [M3devel] 32bit negative base 16 constants? In-Reply-To: <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> References: , <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> Message-ID: I want a 32bit signed value expressed in base 16 where e.g. 16_FFFFFFFF is equivalent to -1. - Jay From: hosking at cs.purdue.edu Date: Thu, 11 Apr 2013 16:03:02 +1000 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] 32bit negative base 16 constants? Actually, writing that you get what you expressed: If an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation uses the convention of the Word interface. Word.T is unsigned, so you only get the 32 bits you asked for. If you want a signed value then you need to express the sign explicitly starting from a constant, just as you have done with: CONST UID_WORD = (* 16_97E237E2 *) -1881139893; On Apr 11, 2013, at 3:14 PM, Jay K wrote: I have some 32bit constants. e.g.: CONST UID_WORD = 16_97E237E2; but this isn't right. On a 64bit system, that is a 64bit integer with a "large" positive value, instead of the intended 32bit negative value. Is there an ideal (i.e. CONST) way to do this? Portably to 64bit systems? I have found two unsatisfactory choices: 1) use decimal: #include int main() { printf("%X %d\n", 0x97E237E2); return 0; } cc 1.c ./a.out 97E237E2 -1881139893 CONST UID_WORD = (* 16_97E237E2 *) -1881139893; 2) change it to VAR and a runtime conversion: PROCEDURE SignExtend(a, b: INTEGER): INTEGER = BEGIN b := Word.LeftShift(-1, b - 1); IF Word.And(a, b) # 0 THEN a := Word.Or(a, b); END; RETURN a; END SignExtend; PROCEDURE SignExtend32(a: INTEGER): INT32 = BEGIN RETURN SignExtend(a, 32); END SignExtend32; CONST IntegerToTypeid = SignExtend32; VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) This gives a warning: CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) and then at runtime gives an error assigning it to an INT32. any other ways? Thanks, - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 10:28:22 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 08:28:22 +0000 Subject: [M3devel] temporary records lack typeids Message-ID: It'd be nice if temporary records had typeids. Specifically, it'd be nice if closures, instead of being "3 word CGType.Struct" where more like declare_record 3 fields typeidxxx declare_field integer marker declare_field address function_pointer declare_field address static_link declare_typename closure = typeidxxx Then: 1) they'd be viewable somewhat in a debugger note that the static_link is up to the backend to define. It is also a pointer to a struct, but the frontend doesn't know that 2) I could soon dispense with my mechanism for declaring structs with size but not particular fields. i.e. #define M3STRUCT(n) m3struct_##n##_t #define M3STRUCT1(n) typedef struct { volatile UINT8 a[n]; } M3STRUCT(n); #define M3STRUCT2(n) typedef struct { volatile UINT16 a[(n)/2]; } M3STRUCT(n); #define M3STRUCT4(n) typedef struct { volatile UINT32 a[(n)/4]; } M3STRUCT(n); #define M3STRUCT8(n) typedef struct { volatile UINT64 a[(n)/8]; } M3STRUCT(n); ... M3STRUCT8(8) M3STRUCT8(24) ... M3STRUCT(24) L_32_L_33 = { 0 }; all structs were using this, but now likely only closures are..er...what is that 8 byte struct? That is also something I'll remove soon, unfinished work making uplevel structs strongly typed. Maybe a long standing bug in the C backend also. I'll know soon.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 20:57:53 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 18:57:53 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend Message-ID: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 11 23:12:42 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Apr 2013 07:12:42 +1000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: References: Message-ID: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: > The C/C++ works, for a while now, and is improving nicely (wrt debuggability). > > > Here are some current problems/dilemnas. > > > --- getting pointer parameters correctly typed esp. on passing side --- > > > Up until now, any pointer parameter to a function has been typed as char*. > > > (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do > math on them; however given that char* is usually wrong, void* actually debugs better, > showing nothing instead of garbage. gcc does allow math on void* but it > is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; > I should probably use void* with gcc and wherever the extension is supported...autoconf...) > Anyway.. > Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). > This works but is bad for debugging (again: void* is better than char*, but both are bad) > I've been working on this. > > > The interface to the backend is > pop_param(cgtype) > pop_struct(typeid, size) > > > non-struct readonly and var parameters are just: > pop_param(cgtype.addr) > > > It would be nice if the frontend also passed a typeid here, > and either using the typeid from a "declare_indirect" or "declare_pointer" > or had separate booleans/flags for readonly/var. > > > How about: > TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); > > > might as well merge this with pop_struct, no further change required probably. > > Or, at worst, another mode: > TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); > > > or less abstract: > TYPE ParameterMode = {Value, Pointer, StructByValue}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); > > > or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, > I like it: > > (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant > Backends without type checking can ignore typeid. e.g. NTx86.m3. > bitSize is definitely redundant, but helps typeid-ignoring backends > that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. > cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) > cgtype will be CGType.Struct for struct-by-value (size in bitSize) > typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) > typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); > > > Ideally all backends would track typeids and it'd suffice to say: > (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) > typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) > PROCEDURE pop_param(typeid: TypeUID); > > > but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. > (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), > and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) > > > I haven't looked to see if this information (typeid/size for pop_param) > is readily available in the frontend. I will do that soon. > > > I have a few potential workarounds: > cast to void* > This appears to be working, with limited testing (my new test case, p254) > Big drawback here is the code is no longer valid C++, only C. > This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. > The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ > doesn't allow conversion from void* to other pointer types without a cast. > > > Introspect on the function pointer type and cast appropriately, or even not at all. > This should provide the ideal output and is probably viable. I'll look into it later. > > > Cast the function to (*)(...) for C++ or (*)() for C. > This is kind of gross. Hopefully it is not a deoptimization, but it might be. > I already do such casting for indirect function calls, for reasons to do with the static link. > I'm going to try this next. > > > --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- > > Now a minor dilemna, not a problem. > > > Up until recently, I didn't have much type information flowing through the C backend. > Or specifically I was only using CGType and not TypeUID. > I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. > (just some loose ends maybe around opaque types and object runtime type information. > > > I had known record sizes, but not fields. Maybe this was a dilemna already before. > > > Anyway, the point is, up until now, record passing and returning by value I have handled > internally by passing around pointers and making copies as needed (at function start). > > > I forget exactly how returning works, I'll deal with that later. > > > Passing works as follows: > caller passes pointer to record > callee has a local variable of that type > callee early on copies pointer to local variable, and references that thereafter > > > This works and has almost no downside. > It is likely how the C compiler implements things anyway. > Except maybe for "small" records/structs. Some calling conventions > do allow for passing structs/records by value in registers. > > > Passing structs/records by value is relatively rare, so we probably don't care much. > > > Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of > passing structs by value? > > > There are multiple choices: > - no, leave it alone > - yes, change it unconditionally > - leave it as a const or var in M3C.m3 > - make it #ifdefed in the output .c > > > I think for returning, we have similar choices, but the frontend is willing > to do the transform and currently does -- a matter of a boolean in Target.i3. > > > This second question has equal quality debugging either way and needs no M3CG/frontend changes > either way. (though, you know, frontend is willing to make more transforms for > record return than record pass, I believe; it probably should be willing to do > more of the work.) > > > Very old compilers don't support passing structs by value? > Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. > > > --- #line directives or not? --- > > > Third question that has been bugging me. > The C backend can output #line directives. > So you step through the Modula-3 source. What people expect. > This was working, and probably still does. > I turned it off subject to a constant in the backend. > Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) > > This is great for, during backend development/debugging, the C compiler gives me C line numbers. > If the backend worked perfectly, this would be pointless. > I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. > There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. > > > What to do to cater to both/everyone? > I wish I could have multiple #line directives: > #line 123 foo.m3.c 456 foo.m3 > > > but that doesn't exit. > I could encode information in the file name: > #line 123 "foo.m3.c/456 foo.m3" > > > but that is imperfect; error messages will be good, but debugging won't work > > > I could leave it as an #ifdef in the code. > I do not believe the following works: > > #ifndef CLINE > #define LINE(cline, cfile, m3line, m3file) cline cfile > #else > #define LINE(cline, cfile, m3line, m3file) m3line m3file > #endif > #line LINE(123, "foo.c", 456, "foo.m3") > > > but I'll try it. > > > I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: > #ifndef CLINE > #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) > #endif > > This is bloated, but might be best. > > > if "#define LINE" works, great, but I doubt it will. > > > --- typeindex besides typeid? --- > > > I'm now doing a lot of lookups of typeids. > It'd be super nice if the frontend also maintained "small" incrementing > typeIndices that I could use to index into an array. > > > set_type_count(typeCount:CARDINAL); (* maybe *) > declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); > > > and thereafter, use typeIndex instead of typeId, an index into an array. > > > I've been tempted to ask for just: > declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); > > > but I realize that preserving the structural hash id is likely too useful/important, > either now or hypothetically. > > > There is then the question as to if begin_unit/end_unit reset typeIndex. > This somewhat depends on how the frontend works. > > > At some point I'd like to try outputing one C file across multiple units, > and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, > M3CG.import_library(static | dynamic | unknown), > so the backend knows which units definitely link together, > and guide ELF visibility/__declspec(dllimport,dllexport). > > > Given that, typeIndices would not reset upon end_unit. > There are challenges here, e.g. separate/incremental compilation. > I would like to amortize C compiler startup, as well, all the type declarations > would be shared across units, so the overall C source smaller. > Computer memory is vastly larger today than when CM3 was written and compilation > strategies have shifted significantly toward "whole program compilation". > We could do similar in the C backend..or leave it to the C compiler to try. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 12 00:19:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 22:19:23 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> References: , <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Message-ID: It is a mix of proposals and what-do-people-prefer-among-working-options andLet me try again. Just some of it. 1) Stronger typing on pop_param. Given INTERFACE I; PROCEDURE A(VAR a:INTEGER); PROCEDURE B() VAR b; BEGIN A(b); END B; I want void I__A(INTEGER* a); void I__B() { INTEGER b; A__I(&b) or A__I((INTEGER*)&b); } unnecessary casts are ok. This is not directly supported in M3CG: current: M3CG.pop_param(type := M3CG.Addr); (* Addr of what ? *) but it might be indirectly supported, i.e. if I look at the function type. Currently, on my machine, I cast to void*, but that isn't valid C++, only C. I might be able to cast the function itself to "untyped" and get away with it, but that is kind ugly too. proposal something like: M3CG.pop_param(CGType, TypeUID); but, furthermore, pop_struct doesn't need to be separate, so just: M3CG.pop_param(CGType, TypeUID, BitSize); and remove pop_struct. Much longer term, merely: M3CG.pop_param(TypeUID); suffices. CGType is generally redundant with TypeUIDs, however existing backends ignore TypeUIDs and get by with CGType. 2) Preference for how to handle passing structs by value in C backend? There are two obvious choices. I'm doing it "manually" because, perhaps, I didn't have good type information. I have good type information now, so I can use the C/C++ feature of passing structs by value, instead of passing a pointer and copying into a local. Works either way. No M3CG interface change. 3) Small dense TypeIndexes mostly-but-not-entirely in place of TypeUIDs. TypeUIDs imply a lot of "lookups" in the backend. Slow seeming. It'd be nice if we had a "linear" TypeIndex as well, that could be indices into a "full" array. Proposal: TypeIndex = CARDINAL; (* index into an array *) (* a separate typename here isn't all that valuable *) M3CG.declare_typeid or declare_typeindex or declare_type(TypeUID, TypeIndex); and possibly M3CG.declare_type_count(CARDINAL); (* maximum value of TypeIndex + 1, backends can allocate arrays of this size and the index by later TypeIndex *) TypeIndexes should take on the values roughly [0..N] where N is the number of types in the "program" (or unit..) and then replace TypeUID everywhere else with TypeIndex. Depending on how the frontend flows, it might not be able to compute TypeCount early enough. That is, I don't know if m3cg calls happen "during compilation" or only "at the end". As well, this does imply likely the same perf/lookups in the frontend. Moving rather than eliminating cost. However, it'd save it from multiple backends, and the frontend might already be paying this cost, I haven't looked yet. It is ok and works today, but I'd really rather have "small" dense integers that can index into an array than "random" integers that I'm forced to use something like a hash table or binary search a sorted array for. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu Subject: Re: [M3devel] many matters big and small esp. wrt C backend Date: Fri, 12 Apr 2013 07:12:42 +1000 To: jay.krell at cornell.edu Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 02:48:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 11 Apr 2013 19:48:11 -0500 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <5165AB6E.8060808@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> Message-ID: <516759CB.4090101@lcwb.coop> After a small clarification to m3-defn-complete.tex, I reran the autogeneration that produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. Many of these are checked-in to CVS, even though mechanically generated. All the html files have many differences. The current checked-in files were built by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, which generates HTML 4.0 Transitional. This information is visible within the html files. In addition, there are many instances of a few kinds of tag changes. Anecdotal examination revealed no content changes. Does anybody have any problems with checking these new versions in? Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, the older html files in cm3/doc/reference, and what we see at the elegosoft website? If I check in the regenerated files into CVS, will they be seen on the website? From wagner at elegosoft.com Fri Apr 12 08:30:30 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 12 Apr 2013 08:30:30 +0200 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <516759CB.4090101@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> Message-ID: <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> On Thu, 11 Apr 2013 19:48:11 -0500 "Rodney M. Bates" wrote: > After a small clarification to m3-defn-complete.tex, I reran the autogeneration that > produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. > Many of these are checked-in to CVS, even though mechanically generated. > > All the html files have many differences. The current checked-in files were built > by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, > which generates HTML 4.0 Transitional. This information is visible within the html files. > In addition, there are many instances of a few kinds of tag changes. Anecdotal examination > revealed no content changes. > > Does anybody have any problems with checking these new versions in? Just go ahead. > Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, > the older html files in cm3/doc/reference, and what we see at the elegosoft website? I think reference/complete is just the language reference, while the level above contains additional information from Critical Mass about the system and libraries. > If I check > in the regenerated files into CVS, will they be seen on the website? There is a script ship-cm3-www-doc which needs to be run; I can do that for you. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Apr 12 09:57:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 07:57:33 +0000 Subject: [M3devel] trestle grandChild.init 5 parameters? Message-ID: can anyone explain this? PROCEDURE InitChild (j: Join; ch: VBT.T; p: DeleteProc)= VAR grandChild := NEW(GrandChild, proc := p); child := StableVBT.New(grandChild); BEGIN EVAL grandChild.init(ch); (* line 41 *) j.trueChild := ch; EVAL j.init(child) END InitChild; There are only two obvious parameters. The generated code passes 5. I understand they could be default parameters, but I still don't see it. My particular problem is that type 79A5AEBB and/or 23E73F69 isn't declared. I'd like to know what they are. If I don't know the full information for every struct passed by value at the point of the call, I won't be able to use the C/C++ feature of passing structs by value. //line 41 "../src/trestle/InstalledVBT.m3" /* start_call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_address */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* check_nil */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_69_L_70))=(ADDRESS)(((ADDRESS)(L_67_L_68))); //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /*check_nil*/if(!L_69_L_70)M_InstalledVBT_L_37_CRASH(1316); //line 41 "../src/trestle/InstalledVBT.m3" /* call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_65_L_66))=(ADDRESS)(((ADDRESS)(((ADDRESS (__cdecl*)(DOTDOTDOT))L_69_L_70)( grandChild_L_45, ch_L_48, ((T79A5AEBB*)(*((ADDRESS*)(INT64_(232)+((ADDRESS)(*((ADDRESS*)(INT64_(984)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), ((T23E73F69*)(*((ADDRESS*)(INT64_(120)+((ADDRESS)(*((ADDRESS*)(INT64_(1008)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), INT64_(72)+((ADDRESS)(&L_35_L_36)))))); -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 17:19:09 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:19:09 -0500 Subject: [M3devel] Another CVS problem: adding a new file Message-ID: <516825ED.9010003@lcwb.coop> m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. cvs checkout says: cvs server: cannot find module `m3-defn-complete.pdf' - ignored When I try to add it, cvs add says: cvs add: `m3-defn-complete.pdf' added independently by second party and when I try to commit, cvs says: cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' cvs [commit aborted]: correct above errors first! From rodney_bates at lcwb.coop Fri Apr 12 17:38:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:38:11 -0500 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <516825ED.9010003@lcwb.coop> References: <516825ED.9010003@lcwb.coop> Message-ID: <51682A63.10709@lcwb.coop> On 04/12/2013 10:19 AM, Rodney M. Bates wrote: > m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. > cvs checkout says: > > cvs server: cannot find module `m3-defn-complete.pdf' - ignored > > When I try to add it, cvs add says: > > cvs add: `m3-defn-complete.pdf' added independently by second party > > and when I try to commit, cvs says: > > cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' > cvs [commit aborted]: correct above errors first! > > And after the above, when I do cvs update on a different computer, cvs says: cvs update: move away `complete/m3-defn-complete.pdf'; it is in the way C complete/m3-defn-complete.pdf And there is indeed a local file by this name. But MORE CVS/Entries gives: /Makefile/1.2/Thu Apr 29 17:20:18 2010// /m3-defn-completeimg1.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /m3-defn-completeimg2.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /nx_grp_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /prev_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /up_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ D/html//// /m3-defn-complete.html/1.4/Fri Apr 12 15:23:26 2013// /m3-defn-complete.ps/1.5/Fri Apr 12 15:23:28 2013/-kb/ /m3-defn-complete.tex/1.22/Wed Apr 10 16:44:07 2013// But again, cvs log m3-defn-complete.pdf gives: RCS file: /usr/cvs/cm3/doc/reference/complete/m3-defn-complete.pdf,v Working file: complete/m3-defn-complete.pdf head: 1.3 branch: locks: strict access list: symbolic names: release_CM3_5_8_6: 1.1.2.4 release_CM3_5_8_RC5: 1.1.2.2 release_branch_cm3_5_8: 1.1.0.2 keyword substitution: b total revisions: 7; selected revisions: 7 description: ---------------------------- revision 1.3 date: 2010-04-29 12:20:18 -0500; author: wagner; state: Exp; lines: +1420 -1410; commitid: HFcCg3x7BkM9jQwu; merge doc changes/extensions from release_branch_cm3_5_8 ---------------------------- which appears to tell me it's in the head and several branches. From jay.krell at cornell.edu Fri Apr 12 17:33:44 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 15:33:44 +0000 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <516825ED.9010003@lcwb.coop> References: <516825ED.9010003@lcwb.coop> Message-ID: CVS is awful. Try this: make sure you have "everything" "backed up" esp. m3-defn-complete.pdf rm -rf the local directory with m3-defn-complete.pdf (that you backed up) cvs upd -dAP to get it back if m3-defn-complete.pdf is there { rm m3-defn-complete.pdf cvs delete m3-defn-complete.pdf cvs commit m3-defn-complete.pdf } copy in your new m3-defn-complete.pdf cvs add m3-defn-complete.pdf cvs commit m3-defn-complete.pdf - Jay > Date: Fri, 12 Apr 2013 10:19:09 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Another CVS problem: adding a new file > > m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. > cvs checkout says: > > cvs server: cannot find module `m3-defn-complete.pdf' - ignored > > When I try to add it, cvs add says: > > cvs add: `m3-defn-complete.pdf' added independently by second party > > and when I try to commit, cvs says: > > cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' > cvs [commit aborted]: correct above errors first! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 12 18:05:34 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 16:05:34 +0000 Subject: [M3devel] m3front/Force_pair Message-ID: m3front/misc/CG.m3 PROCEDURE Force_pair (commute: BOOLEAN): BOOLEAN = (* Returns TRUE if the items are stacked in the wrong order *) VAR s1 := stack [SCheck (1, "Force_pair")].kind = VKind.Stacked; VAR s2 := stack [SCheck (2, "Force_pair")].kind = VKind.Stacked; BEGIN IF s1 AND s2 THEN (* both elements are already stacked *) RETURN FALSE; ELSIF s2 THEN (* bottom element is already stacked *) Force (); RETURN FALSE; ELSIF s1 THEN Swap (); Force (); IF commute THEN RETURN TRUE END; Swap (); RETURN FALSE; ELSE (* neither element is stacked *) Swap (); Force (); Swap (); Force (); RETURN FALSE; END; END Force_pair; Shouldn't the last part be: ELSE (* neither element is stacked *) IF commute THEN Force (); Swap (); Force (); RETURN TRUE; END; Swap (); Force (); Swap (); Force (); RETURN FALSE; END; ? Probably there is a way to write the function with less duplication. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 17:01:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:01:40 -0500 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> Message-ID: <516821D4.6050001@lcwb.coop> On 04/12/2013 01:30 AM, Olaf Wagner wrote: > On Thu, 11 Apr 2013 19:48:11 -0500 > "Rodney M. Bates" wrote: > >> After a small clarification to m3-defn-complete.tex, I reran the autogeneration that >> produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. >> Many of these are checked-in to CVS, even though mechanically generated. >> >> All the html files have many differences. The current checked-in files were built >> by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, >> which generates HTML 4.0 Transitional. This information is visible within the html files. >> In addition, there are many instances of a few kinds of tag changes. Anecdotal examination >> revealed no content changes. >> >> Does anybody have any problems with checking these new versions in? > > Just go ahead. Done, in the head. > >> Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, >> the older html files in cm3/doc/reference, and what we see at the elegosoft website? > > I think reference/complete is just the language reference, while the level above > contains additional information from Critical Mass about the system and libraries. > >> If I check >> in the regenerated files into CVS, will they be seen on the website? > > There is a script ship-cm3-www-doc which needs to be run; I can do that > for you. 1) Does it ship from head or release branch? 2) Can I do it myself, in case this happens again? > > Olaf > From jay.krell at cornell.edu Sat Apr 13 02:13:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Apr 2013 00:13:56 +0000 Subject: [M3devel] trestle grandChild.init 5 parameters? In-Reply-To: References: Message-ID: duh, 5 parameters, HighlightVBT: Public = Filter.T OBJECT METHODS init( ch: VBT.T; op: PaintOp.T := PaintOp.TransparentSwap; txt: Pixmap.T := Pixmap.Gray; READONLY delta := Point.T{h := 0, v := 1}): T END; note that if you make multiple calls, the compiler generates that const/static Point.T for each call, wasteful op and txt get single instanced. PaintOp.T = RECORD op:INTEGER END; Predefined = [0..16]; PixMap.T = RECORD pm: INTEGER END; Predefined = [0..2]; so then, this looks like a frontend bug. Of those three types, at least one is not described to the backend when compiling InstalledVBT.m3, inhibiting the C backend from using C's feature of passing structs by value, forcing us to generate code to pass a pointer and copy it into a local. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 12 Apr 2013 07:57:33 +0000 Subject: [M3devel] trestle grandChild.init 5 parameters? can anyone explain this? PROCEDURE InitChild (j: Join; ch: VBT.T; p: DeleteProc)= VAR grandChild := NEW(GrandChild, proc := p); child := StableVBT.New(grandChild); BEGIN EVAL grandChild.init(ch); (* line 41 *) j.trueChild := ch; EVAL j.init(child) END InitChild; There are only two obvious parameters. The generated code passes 5. I understand they could be default parameters, but I still don't see it. My particular problem is that type 79A5AEBB and/or 23E73F69 isn't declared. I'd like to know what they are. If I don't know the full information for every struct passed by value at the point of the call, I won't be able to use the C/C++ feature of passing structs by value. //line 41 "../src/trestle/InstalledVBT.m3" /* start_call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_address */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* check_nil */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_69_L_70))=(ADDRESS)(((ADDRESS)(L_67_L_68))); //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /*check_nil*/if(!L_69_L_70)M_InstalledVBT_L_37_CRASH(1316); //line 41 "../src/trestle/InstalledVBT.m3" /* call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_65_L_66))=(ADDRESS)(((ADDRESS)(((ADDRESS (__cdecl*)(DOTDOTDOT))L_69_L_70)( grandChild_L_45, ch_L_48, ((T79A5AEBB*)(*((ADDRESS*)(INT64_(232)+((ADDRESS)(*((ADDRESS*)(INT64_(984)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), ((T23E73F69*)(*((ADDRESS*)(INT64_(120)+((ADDRESS)(*((ADDRESS*)(INT64_(1008)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), INT64_(72)+((ADDRESS)(&L_35_L_36)))))); -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sat Apr 13 02:39:06 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sat, 13 Apr 2013 00:39:06 +0000 Subject: [M3devel] EXT: Auto-generated html documentation and new tools In-Reply-To: <516759CB.4090101@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF0C2807AC@ATLEX04-SRV.SCIRES.LOCAL> Rodney: If I remember correctly, I think the files in cm3/doc are those that are supposed to form the doc subfolder of the cm3ide installation (formerly Reactor). I think there are some scripts that are supposed to update the generated files. Thus, back in the day when Critical Mass was selling their product, I think they ran the scripts to populate the doc folder before making a release of the product onto CD-ROM. Then, during the customer's installation, the doc folder would get pushed to the customer's hard drive. I know that cm3ide expects to find certain information in the doc folder. Hope this helps a bit. --Randy -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Thursday, April 11, 2013 8:48 PM To: m3devel Subject: EXT:[M3devel] Auto-generated html documentation and new tools After a small clarification to m3-defn-complete.tex, I reran the autogeneration that produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. Many of these are checked-in to CVS, even though mechanically generated. All the html files have many differences. The current checked-in files were built by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, which generates HTML 4.0 Transitional. This information is visible within the html files. In addition, there are many instances of a few kinds of tag changes. Anecdotal examination revealed no content changes. Does anybody have any problems with checking these new versions in? Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, the older html files in cm3/doc/reference, and what we see at the elegosoft website? If I check in the regenerated files into CVS, will they be seen on the website? From jay.krell at cornell.edu Sat Apr 13 04:44:40 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Apr 2013 02:44:40 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: References: , , <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>, Message-ID: > M3CG.pop_param(CGType, TypeUID, BitSize); I was able to get away without this because I know the signature of the function for direct calls. So far I don't strongly type function pointers. And because of the static link, I'm not sure I can. I'm not sure it matters. For debugging, it only matters when you step through to the called function, and I declare them all now quite typefully. I still think this is a very good idea though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 11 Apr 2013 22:19:23 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] many matters big and small esp. wrt C backend It is a mix of proposals and what-do-people-prefer-among-working-options and Let me try again. Just some of it. 1) Stronger typing on pop_param. Given INTERFACE I; PROCEDURE A(VAR a:INTEGER); PROCEDURE B() VAR b; BEGIN A(b); END B; I want void I__A(INTEGER* a); void I__B() { INTEGER b; A__I(&b) or A__I((INTEGER*)&b); } unnecessary casts are ok. This is not directly supported in M3CG: current: M3CG.pop_param(type := M3CG.Addr); (* Addr of what ? *) but it might be indirectly supported, i.e. if I look at the function type. Currently, on my machine, I cast to void*, but that isn't valid C++, only C. I might be able to cast the function itself to "untyped" and get away with it, but that is kind ugly too. proposal something like: M3CG.pop_param(CGType, TypeUID); but, furthermore, pop_struct doesn't need to be separate, so just: M3CG.pop_param(CGType, TypeUID, BitSize); and remove pop_struct. Much longer term, merely: M3CG.pop_param(TypeUID); suffices. CGType is generally redundant with TypeUIDs, however existing backends ignore TypeUIDs and get by with CGType. 2) Preference for how to handle passing structs by value in C backend? There are two obvious choices. I'm doing it "manually" because, perhaps, I didn't have good type information. I have good type information now, so I can use the C/C++ feature of passing structs by value, instead of passing a pointer and copying into a local. Works either way. No M3CG interface change. 3) Small dense TypeIndexes mostly-but-not-entirely in place of TypeUIDs. TypeUIDs imply a lot of "lookups" in the backend. Slow seeming. It'd be nice if we had a "linear" TypeIndex as well, that could be indices into a "full" array. Proposal: TypeIndex = CARDINAL; (* index into an array *) (* a separate typename here isn't all that valuable *) M3CG.declare_typeid or declare_typeindex or declare_type(TypeUID, TypeIndex); and possibly M3CG.declare_type_count(CARDINAL); (* maximum value of TypeIndex + 1, backends can allocate arrays of this size and the index by later TypeIndex *) TypeIndexes should take on the values roughly [0..N] where N is the number of types in the "program" (or unit..) and then replace TypeUID everywhere else with TypeIndex. Depending on how the frontend flows, it might not be able to compute TypeCount early enough. That is, I don't know if m3cg calls happen "during compilation" or only "at the end". As well, this does imply likely the same perf/lookups in the frontend. Moving rather than eliminating cost. However, it'd save it from multiple backends, and the frontend might already be paying this cost, I haven't looked yet. It is ok and works today, but I'd really rather have "small" dense integers that can index into an array than "random" integers that I'm forced to use something like a hash table or binary search a sorted array for. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu Subject: Re: [M3devel] many matters big and small esp. wrt C backend Date: Fri, 12 Apr 2013 07:12:42 +1000 To: jay.krell at cornell.edu Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 13 08:52:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 13 Apr 2013 08:52:28 +0200 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: References: <516825ED.9010003@lcwb.coop> Message-ID: Never ending story :). To make it short - let's move to git! :) On Apr 12, 2013, at 5:33 PM, Jay K wrote: > CVS is awful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 13 14:44:34 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 13 Apr 2013 14:44:34 +0200 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <516821D4.6050001@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> <516821D4.6050001@lcwb.coop> Message-ID: <20130413144434.63c30578edad59441166d5e9@elegosoft.com> On Fri, 12 Apr 2013 10:01:40 -0500 "Rodney M. Bates" wrote: > On 04/12/2013 01:30 AM, Olaf Wagner wrote: > > On Thu, 11 Apr 2013 19:48:11 -0500 > > "Rodney M. Bates" wrote: > > > >> After a small clarification to m3-defn-complete.tex, I reran the autogeneration that > >> produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. > >> Many of these are checked-in to CVS, even though mechanically generated. > >> > >> All the html files have many differences. The current checked-in files were built > >> by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, > >> which generates HTML 4.0 Transitional. This information is visible within the html files. > >> In addition, there are many instances of a few kinds of tag changes. Anecdotal examination > >> revealed no content changes. > >> > >> Does anybody have any problems with checking these new versions in? > > > > Just go ahead. > > Done, in the head. I've checked out head and ran the scripts; results see below. > > > > >> Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, > >> the older html files in cm3/doc/reference, and what we see at the elegosoft website? > > > > I think reference/complete is just the language reference, while the level above > > contains additional information from Critical Mass about the system and libraries. > > > >> If I check > >> in the regenerated files into CVS, will they be seen on the website? > > > > There is a script ship-cm3-www-doc which needs to be run; I can do that > > for you. > > 1) Does it ship from head or release branch? The scripts just ships what it finds in the workspace. I think we only ever shipped from head, but am not sure. > 2) Can I do it myself, in case this happens again? You need to be in the m3 group I think, but that's the case: % id rodney uid=6011(rodney) gid=6011(rodney) groups=6011(rodney),200(m3),10004(tinderbox) So you should be able to ship the documentation yourself, too. Olaf --- Updated documents --- birch [/var/www/modula3.elegosoft.com/cm3/doc] wagner % find . -mtime -1 -print | xargs ls -ld drwxrwsr-x 8 www-data m3 4096 2013-04-13 14:36 . drwxrwsr-x 8 root m3 4096 2013-04-13 14:36 ./help -rwxrwsr-x 1 wagner m3 39110 2013-04-13 14:36 ./help/bib.html drwxrwsr-x 4 root m3 4096 2013-04-13 14:36 ./help/cm3 -rw-rwSr-- 1 wagner m3 5215 2013-04-13 14:36 ./help/cm3/acks.html -rw-rwSr-- 1 wagner m3 2055 2013-04-13 14:36 ./help/cm3/cm3.html -rw-rwSr-- 1 wagner m3 4225 2013-04-13 14:36 ./help/cm3/cm3-quickref.html -rw-rwSr-- 1 wagner m3 798 2013-04-13 14:36 ./help/cm3/compiling.html -rw-rwSr-- 1 wagner m3 5198 2013-04-13 14:36 ./help/cm3/debugging.html -rw-rwSr-- 1 wagner m3 2129 2013-04-13 14:36 ./help/cm3/files.html -rw-rwSr-- 1 wagner m3 2033 2013-04-13 14:36 ./help/cm3/gc.html -rw-rwSr-- 1 wagner m3 5868 2013-04-13 14:36 ./help/cm3/gnuemacs.html -rw-rwSr-- 1 wagner m3 11684 2013-04-13 14:36 ./help/cm3/history.html -rw-rwSr-- 1 wagner m3 3146 2013-04-13 14:36 ./help/cm3/m3args.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./help/cm3/m3build -rw-rwSr-- 1 wagner m3 534 2013-04-13 14:36 ./help/cm3/m3build/emacs.html -rw-rwSr-- 1 wagner m3 1936 2013-04-13 14:36 ./help/cm3/m3build/exports.html -rw-rwSr-- 1 wagner m3 652 2013-04-13 14:36 ./help/cm3/m3build/foreign.html -rw-rwSr-- 1 wagner m3 3371 2013-04-13 14:36 ./help/cm3/m3build/generics.html -rw-rwSr-- 1 wagner m3 1216 2013-04-13 14:36 ./help/cm3/m3build/hiding.html -rw-rwSr-- 1 wagner m3 1258 2013-04-13 14:36 ./help/cm3/m3build/imports.html -rw-rwSr-- 1 wagner m3 3316 2013-04-13 14:36 ./help/cm3/m3build/m3build.html -rw-rwSr-- 1 wagner m3 951 2013-04-13 14:36 ./help/cm3/m3build/m3makefile.html -rw-rwSr-- 1 wagner m3 1246 2013-04-13 14:36 ./help/cm3/m3build/m3options.html -rw-rwSr-- 1 wagner m3 2484 2013-04-13 14:36 ./help/cm3/m3build/machine.html -rw-rwSr-- 1 wagner m3 763 2013-04-13 14:36 ./help/cm3/m3build/manpage.html -rw-rwSr-- 1 wagner m3 1131 2013-04-13 14:36 ./help/cm3/m3build/misc.html -rw-rwSr-- 1 wagner m3 662 2013-04-13 14:36 ./help/cm3/m3build/netobj.html -rw-rwSr-- 1 wagner m3 947 2013-04-13 14:36 ./help/cm3/m3build/noweb.html -rw-rwSr-- 1 wagner m3 3366 2013-04-13 14:36 ./help/cm3/m3build/options.html -rw-rwSr-- 1 wagner m3 1525 2013-04-13 14:36 ./help/cm3/m3build/overrides.html -rw-rwSr-- 1 wagner m3 956 2013-04-13 14:36 ./help/cm3/m3build/progs.html -rw-rwSr-- 1 wagner m3 958 2013-04-13 14:36 ./help/cm3/m3build/resources.html -rw-rwSr-- 1 wagner m3 2811 2013-04-13 14:36 ./help/cm3/m3build/sources.html -rw-rwSr-- 1 wagner m3 644 2013-04-13 14:36 ./help/cm3/m3ship.html -rw-rwSr-- 1 wagner m3 410 2013-04-13 14:36 ./help/cm3/m3where.html -rw-rwSr-- 1 wagner m3 18647 2013-04-13 14:36 ./help/cm3/old-bib.html -rw-rwSr-- 1 wagner m3 2816 2013-04-13 14:36 ./help/cm3/packages.html -rw-rwSr-- 1 wagner m3 10450 2013-04-13 14:36 ./help/cm3/pprint.html -rw-rwSr-- 1 wagner m3 10432 2013-04-13 14:36 ./help/cm3/pragmas.html -rw-rwSr-- 1 wagner m3 33312 2013-04-13 14:36 ./help/cm3/quake.html -rw-rwSr-- 1 wagner m3 3660 2013-04-13 14:36 ./help/cm3/restrictions.html -rw-rwSr-- 1 wagner m3 3449 2013-04-13 14:36 ./help/cm3/runtime.html -rw-rwSr-- 1 wagner m3 3346 2013-04-13 14:36 ./help/cm3/scheduler.html -rw-rwSr-- 1 wagner m3 3054 2013-04-13 14:36 ./help/cm3/showheap.html -rw-rwSr-- 1 wagner m3 947 2013-04-13 14:36 ./help/cm3/shownew.html -rw-rwSr-- 1 wagner m3 1778 2013-04-13 14:36 ./help/cm3/showthread.html -rw-rwSr-- 1 wagner m3 1339 2013-04-13 14:36 ./help/cm3/signals.html -rwxrwsr-x 1 wagner m3 4194 2013-04-13 14:36 ./help/concise-bib.html -rwxrwsr-x 1 wagner m3 20380 2013-04-13 14:36 ./help/getting-started.html -rwxrwsr-x 1 wagner m3 3948 2013-04-13 14:36 ./help/index.html -rwxrwsr-x 1 wagner m3 51629 2013-04-13 14:36 ./help/interfaces.html drwxrwsr-x 2 wagner m3 4096 2013-04-13 14:36 ./help/m3gdb -rw-rwSr-- 1 wagner m3 53432 2013-04-13 14:36 ./help/m3gdb/m3gdb.docbook -rw-rwSr-- 1 wagner m3 63275 2013-04-13 14:36 ./help/m3gdb/m3gdb-onepage.html -rw-rwSr-- 1 wagner m3 4133 2013-04-13 14:36 ./index.html drwxrwsr-x 2 wagner m3 4096 2013-04-13 14:36 ./notes -rw-rw-r-- 1 wagner m3 2401 2013-04-13 14:36 ./notes/building-old.txt -rw-rw-r-- 1 wagner m3 16 2013-04-13 14:36 ./notes/object-model.txt -rw-rw-r-- 1 wagner m3 12811 2013-04-13 14:36 ./notes/porting.txt -rw-rw-r-- 1 wagner m3 8642 2013-04-13 14:36 ./notes/todo.txt -rw-rwSr-- 1 wagner m3 303039 2013-04-13 14:36 ./PkgDesc drwxrwsr-x 4 root m3 4096 2013-04-13 14:36 ./reference drwxrwxr-x 4 wagner m3 4096 2013-04-13 14:36 ./reference/complete drwxrwxr-x 2 wagner wagner 4096 2013-04-13 14:36 ./reference/complete/html -rw-r--r-- 1 wagner wagner 3945 2013-04-13 14:36 ./reference/complete/html/0_0_0_11_4_1_Interfaces.html -rw-r--r-- 1 wagner wagner 5814 2013-04-13 14:36 ./reference/complete/html/0_0_0_21_4_2_Objects.html -rw-r--r-- 1 wagner wagner 3937 2013-04-13 14:36 ./reference/complete/html/0_0_0_31_4_3_Generics.html -rw-r--r-- 1 wagner wagner 4981 2013-04-13 14:36 ./reference/complete/html/0_0_0_41_4_4_Threads.html -rw-r--r-- 1 wagner wagner 4554 2013-04-13 14:36 ./reference/complete/html/0_0_0_51_4_5_Safety.html -rw-r--r-- 1 wagner wagner 5003 2013-04-13 14:36 ./reference/complete/html/0_0_0_61_4_6_Garbage.html -rw-r--r-- 1 wagner wagner 3845 2013-04-13 14:36 ./reference/complete/html/0_0_0_71_4_7_Exceptions.html -rw-r--r-- 1 wagner wagner 4413 2013-04-13 14:36 ./reference/complete/html/0_0_0_81_4_8_Type.html -rw-r--r-- 1 wagner wagner 4122 2013-04-13 14:36 ./reference/complete/html/0_0_0_91_4_9_Simplicity.html -rw-r--r-- 1 wagner wagner 4318 2013-04-13 14:36 ./reference/complete/html/1_1History.html -rw-r--r-- 1 wagner wagner 7264 2013-04-13 14:36 ./reference/complete/html/1_2Perspective.html -rw-r--r-- 1 wagner wagner 2027 2013-04-13 14:36 ./reference/complete/html/1_3Overview.html -rw-r--r-- 1 wagner wagner 3914 2013-04-13 14:36 ./reference/complete/html/1_4Features.html -rw-r--r-- 1 wagner wagner 2635 2013-04-13 14:36 ./reference/complete/html/1_Introduction.html -rw-r--r-- 1 wagner wagner 5124 2013-04-13 14:36 ./reference/complete/html/2_1Definitions.html -rw-r--r-- 1 wagner wagner 6857 2013-04-13 14:36 ./reference/complete/html/2_2_10Subtyping_rules.html -rw-r--r-- 1 wagner wagner 2159 2013-04-13 14:36 ./reference/complete/html/2_2_11Predeclared_opaque.html -rw-r--r-- 1 wagner wagner 6907 2013-04-13 14:36 ./reference/complete/html/2_2_1Ordinal_types.html -rw-r--r-- 1 wagner wagner 2095 2013-04-13 14:36 ./reference/complete/html/2_2_2Floating_point_types.html -rw-r--r-- 1 wagner wagner 6083 2013-04-13 14:36 ./reference/complete/html/2_2_3Arrays.html -rw-r--r-- 1 wagner wagner 4807 2013-04-13 14:36 ./reference/complete/html/2_2_4Records.html -rw-r--r-- 1 wagner wagner 2695 2013-04-13 14:36 ./reference/complete/html/2_2_5Packed_types.html -rw-r--r-- 1 wagner wagner 2538 2013-04-13 14:36 ./reference/complete/html/2_2_6Sets.html -rw-r--r-- 1 wagner wagner 5344 2013-04-13 14:36 ./reference/complete/html/2_2_7References.html -rw-r--r-- 1 wagner wagner 7931 2013-04-13 14:36 ./reference/complete/html/2_2_8Procedures.html -rw-r--r-- 1 wagner wagner 11577 2013-04-13 14:36 ./reference/complete/html/2_2_9Objects.html -rw-r--r-- 1 wagner wagner 5975 2013-04-13 14:36 ./reference/complete/html/2_2Types.html -rw-r--r-- 1 wagner wagner 2406 2013-04-13 14:36 ./reference/complete/html/2_3_10Exit.html -rw-r--r-- 1 wagner wagner 2917 2013-04-13 14:36 ./reference/complete/html/2_3_11Return.html -rw-r--r-- 1 wagner wagner 3079 2013-04-13 14:36 ./reference/complete/html/2_3_12If.html -rw-r--r-- 1 wagner wagner 2013 2013-04-13 14:36 ./reference/complete/html/2_3_13While.html -rw-r--r-- 1 wagner wagner 2014 2013-04-13 14:36 ./reference/complete/html/2_3_14Repeat.html -rw-r--r-- 1 wagner wagner 3114 2013-04-13 14:36 ./reference/complete/html/2_3_15With.html -rw-r--r-- 1 wagner wagner 4537 2013-04-13 14:36 ./reference/complete/html/2_3_16For.html -rw-r--r-- 1 wagner wagner 3315 2013-04-13 14:36 ./reference/complete/html/2_3_17Case.html -rw-r--r-- 1 wagner wagner 5596 2013-04-13 14:36 ./reference/complete/html/2_3_18Typecase.html -rw-r--r-- 1 wagner wagner 2207 2013-04-13 14:36 ./reference/complete/html/2_3_19Lock.html -rw-r--r-- 1 wagner wagner 5701 2013-04-13 14:36 ./reference/complete/html/2_3_1Assignment.html -rw-r--r-- 1 wagner wagner 2603 2013-04-13 14:36 ./reference/complete/html/2_3_20Inc_Dec.html -rw-r--r-- 1 wagner wagner 6677 2013-04-13 14:36 ./reference/complete/html/2_3_2Procedure_call.html -rw-r--r-- 1 wagner wagner 2111 2013-04-13 14:36 ./reference/complete/html/2_3_3Eval.html -rw-r--r-- 1 wagner wagner 2253 2013-04-13 14:36 ./reference/complete/html/2_3_4Block_statement.html -rw-r--r-- 1 wagner wagner 2391 2013-04-13 14:36 ./reference/complete/html/2_3_5Sequential_composition.html -rw-r--r-- 1 wagner wagner 2430 2013-04-13 14:36 ./reference/complete/html/2_3_6Raise.html -rw-r--r-- 1 wagner wagner 6290 2013-04-13 14:36 ./reference/complete/html/2_3_7Try_Except.html -rw-r--r-- 1 wagner wagner 2388 2013-04-13 14:36 ./reference/complete/html/2_3_8Try_Finally.html -rw-r--r-- 1 wagner wagner 2051 2013-04-13 14:36 ./reference/complete/html/2_3_9Loop.html -rw-r--r-- 1 wagner wagner 5794 2013-04-13 14:36 ./reference/complete/html/2_3Statements.html -rw-r--r-- 1 wagner wagner 2088 2013-04-13 14:36 ./reference/complete/html/2_4_1Types.html -rw-r--r-- 1 wagner wagner 2263 2013-04-13 14:36 ./reference/complete/html/2_4_2Constants.html -rw-r--r-- 1 wagner wagner 4207 2013-04-13 14:36 ./reference/complete/html/2_4_3Variables.html -rw-r--r-- 1 wagner wagner 3001 2013-04-13 14:36 ./reference/complete/html/2_4_4Procedures.html -rw-r--r-- 1 wagner wagner 2296 2013-04-13 14:36 ./reference/complete/html/2_4_5Exceptions.html -rw-r--r-- 1 wagner wagner 2892 2013-04-13 14:36 ./reference/complete/html/2_4_6Opaque_types.html -rw-r--r-- 1 wagner wagner 5433 2013-04-13 14:36 ./reference/complete/html/2_4_7Revelations.html -rw-r--r-- 1 wagner wagner 3462 2013-04-13 14:36 ./reference/complete/html/2_4_8Recursive_declarations.html -rw-r--r-- 1 wagner wagner 3798 2013-04-13 14:36 ./reference/complete/html/2_4Declarations.html -rw-r--r-- 1 wagner wagner 3383 2013-04-13 14:36 ./reference/complete/html/2_5_1Import_statements.html -rw-r--r-- 1 wagner wagner 2425 2013-04-13 14:36 ./reference/complete/html/2_5_2Interfaces.html -rw-r--r-- 1 wagner wagner 5208 2013-04-13 14:36 ./reference/complete/html/2_5_3Modules.html -rw-r--r-- 1 wagner wagner 3081 2013-04-13 14:36 ./reference/complete/html/2_5_4Example_module.html -rw-r--r-- 1 wagner wagner 6960 2013-04-13 14:36 ./reference/complete/html/2_5_5Generics.html -rw-r--r-- 1 wagner wagner 2752 2013-04-13 14:36 ./reference/complete/html/2_5_6Initialization.html -rw-r--r-- 1 wagner wagner 2719 2013-04-13 14:36 ./reference/complete/html/2_5_7Safety.html -rw-r--r-- 1 wagner wagner 5991 2013-04-13 14:36 ./reference/complete/html/2_5Modules_interfaces.html -rw-r--r-- 1 wagner wagner 9402 2013-04-13 14:36 ./reference/complete/html/2_6_10Arithmetic_operations.html -rw-r--r-- 1 wagner wagner 5613 2013-04-13 14:36 ./reference/complete/html/2_6_11Relations.html -rw-r--r-- 1 wagner wagner 2602 2013-04-13 14:36 ./reference/complete/html/2_6_12Boolean_operations.html -rw-r--r-- 1 wagner wagner 8300 2013-04-13 14:36 ./reference/complete/html/2_6_13Type_operations.html -rw-r--r-- 1 wagner wagner 2147 2013-04-13 14:36 ./reference/complete/html/2_6_14Text_operations.html -rw-r--r-- 1 wagner wagner 2741 2013-04-13 14:36 ./reference/complete/html/2_6_15Constant_expressions.html -rw-r--r-- 1 wagner wagner 4521 2013-04-13 14:36 ./reference/complete/html/2_6_1Conventions_describing.html -rw-r--r-- 1 wagner wagner 5968 2013-04-13 14:36 ./reference/complete/html/2_6_2Operation_syntax.html -rw-r--r-- 1 wagner wagner 7552 2013-04-13 14:36 ./reference/complete/html/2_6_3Designators.html -rw-r--r-- 1 wagner wagner 5538 2013-04-13 14:36 ./reference/complete/html/2_6_4Numeric_literals.html -rw-r--r-- 1 wagner wagner 5517 2013-04-13 14:36 ./reference/complete/html/2_6_5Text_character.html -rw-r--r-- 1 wagner wagner 2018 2013-04-13 14:36 ./reference/complete/html/2_6_6Nil.html -rw-r--r-- 1 wagner wagner 2005 2013-04-13 14:36 ./reference/complete/html/2_6_7Function_application.html -rw-r--r-- 1 wagner wagner 4701 2013-04-13 14:36 ./reference/complete/html/2_6_8Set_array.html -rw-r--r-- 1 wagner wagner 5235 2013-04-13 14:36 ./reference/complete/html/2_6_9New.html -rw-r--r-- 1 wagner wagner 4118 2013-04-13 14:36 ./reference/complete/html/2_6Expressions.html -rw-r--r-- 1 wagner wagner 7050 2013-04-13 14:36 ./reference/complete/html/2_7Unsafe_operations.html -rw-r--r-- 1 wagner wagner 2724 2013-04-13 14:36 ./reference/complete/html/2_8_10Expression_production.html -rw-r--r-- 1 wagner wagner 2108 2013-04-13 14:36 ./reference/complete/html/2_8_11Miscellaneous_product.html -rw-r--r-- 1 wagner wagner 3747 2013-04-13 14:36 ./reference/complete/html/2_8_12Token_productions.html -rw-r--r-- 1 wagner wagner 2518 2013-04-13 14:36 ./reference/complete/html/2_8_1Keywords.html -rw-r--r-- 1 wagner wagner 2346 2013-04-13 14:36 ./reference/complete/html/2_8_2Reserved_identifiers.html -rw-r--r-- 1 wagner wagner 2132 2013-04-13 14:36 ./reference/complete/html/2_8_3Operators.html -rw-r--r-- 1 wagner wagner 1990 2013-04-13 14:36 ./reference/complete/html/2_8_4Comments.html -rw-r--r-- 1 wagner wagner 2863 2013-04-13 14:36 ./reference/complete/html/2_8_5Pragmas.html -rw-r--r-- 1 wagner wagner 3274 2013-04-13 14:36 ./reference/complete/html/2_8_6Conventions_syntax.html -rw-r--r-- 1 wagner wagner 3429 2013-04-13 14:36 ./reference/complete/html/2_8_7Compilation_unit.html -rw-r--r-- 1 wagner wagner 3102 2013-04-13 14:36 ./reference/complete/html/2_8_8Statement_productions.html -rw-r--r-- 1 wagner wagner 2883 2013-04-13 14:36 ./reference/complete/html/2_8_9Type_productions.html -rw-r--r-- 1 wagner wagner 3389 2013-04-13 14:36 ./reference/complete/html/2_8Syntax.html -rw-r--r-- 1 wagner wagner 5009 2013-04-13 14:36 ./reference/complete/html/About_authors.html -rw-r--r-- 1 wagner wagner 2407 2013-04-13 14:36 ./reference/complete/html/About_this_document.html -rw-r--r-- 1 wagner wagner 4672 2013-04-13 14:36 ./reference/complete/html/Acknowledgments.html -rw-r--r-- 1 wagner wagner 3951 2013-04-13 14:36 ./reference/complete/html/Contents.html -rw-rw-r-- 1 wagner wagner 178 2013-04-13 14:36 ./reference/complete/html/img1.png -rw-rw-r-- 1 wagner wagner 348 2013-04-13 14:36 ./reference/complete/html/img2.png -rw-r--r-- 1 wagner wagner 1752 2013-04-13 14:36 ./reference/complete/html/index.html -rw-r--r-- 1 wagner wagner 1752 2013-04-13 14:36 ./reference/complete/html/m3-defn-complete.html -rw-r--r-- 1 wagner wagner 5770 2013-04-13 14:36 ./reference/complete/html/Modula_3_Language_definitio.html -rw-rw-r-- 1 wagner wagner 272 2013-04-13 14:36 ./reference/complete/html/next_g.png -rw-rw-r-- 1 wagner wagner 245 2013-04-13 14:36 ./reference/complete/html/next.png -rw-rw-r-- 1 wagner wagner 327 2013-04-13 14:36 ./reference/complete/html/prev_g.png -rw-rw-r-- 1 wagner wagner 279 2013-04-13 14:36 ./reference/complete/html/prev.png -rw-rw-r-- 1 wagner wagner 231 2013-04-13 14:36 ./reference/complete/html/up_g.png -rw-rw-r-- 1 wagner wagner 211 2013-04-13 14:36 ./reference/complete/html/up.png -rw-r--r-- 1 wagner wagner 185985 2013-04-13 14:36 ./reference/complete/m3-defn-complete.html -rw-rw-r-- 1 wagner wagner 178 2013-04-13 14:36 ./reference/complete/m3-defn-completeimg1.png -rw-rw-r-- 1 wagner wagner 348 2013-04-13 14:36 ./reference/complete/m3-defn-completeimg2.png -rw-rw-r-- 1 wagner wagner 307268 2013-04-13 14:36 ./reference/complete/m3-defn-complete.pdf -rw-rw-r-- 1 wagner wagner 335290 2013-04-13 14:36 ./reference/complete/m3-defn-complete.ps -rw-rw-r-- 1 wagner wagner 163695 2013-04-13 14:36 ./reference/complete/m3-defn-complete.tex -rw-rw-r-- 1 wagner wagner 1329 2013-04-13 14:36 ./reference/complete/Makefile -rw-rw-r-- 1 wagner wagner 386 2013-04-13 14:36 ./reference/complete/nx_grp_g.png -rw-rw-r-- 1 wagner wagner 327 2013-04-13 14:36 ./reference/complete/prev_g.png -rw-rw-r-- 1 wagner wagner 231 2013-04-13 14:36 ./reference/complete/up_g.png -rw-rw-r-- 1 wagner m3 10933 2013-04-13 14:36 ./reference/syntax.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./src_reports drwxrwsr-x 2 root m3 4096 2013-04-13 14:36 ./src_reports/blue_paper -r-xrwsr-x 1 wagner m3 34882 2013-04-13 14:36 ./src_reports/blue_paper/architecture_full.gif -r-xrwsr-x 1 wagner m3 20579 2013-04-13 14:36 ./src_reports/blue_paper/architecture.gif -r-xrwsr-x 1 wagner m3 14458 2013-04-13 14:36 ./src_reports/blue_paper/bg.gif -r-xrwsr-x 1 wagner m3 8713 2013-04-13 14:36 ./src_reports/blue_paper/blueLogo.gif -r-xrwsr-x 1 wagner m3 848 2013-04-13 14:36 ./src_reports/blue_paper/dark.gif -rwxrwsr-x 1 wagner m3 37227 2013-04-13 14:36 ./src_reports/blue_paper/index.html -r-xrwsr-x 1 wagner m3 840 2013-04-13 14:36 ./src_reports/blue_paper/light.gif -r-xrwsr-x 1 wagner m3 98030 2013-04-13 14:36 ./src_reports/blue_paper/screen_full.gif -r-xrwsr-x 1 wagner m3 53169 2013-04-13 14:36 ./src_reports/blue_paper/screen.gif -r-xrwsr-x 1 wagner m3 104 2013-04-13 14:36 ./src_reports/doc.gif -r-xrwsr-x 1 wagner m3 683909 2013-04-13 14:36 ./src_reports/formsvbt.pdf -r-xrwsr-x 1 wagner m3 346858 2013-04-13 14:36 ./src_reports/formsvbt.ps.gz -rwxrwsr-x 1 wagner m3 8662 2013-04-13 14:36 ./src_reports/index.html -rwxrwsr-x 1 wagner m3 1624 2013-04-13 14:36 ./src_reports/license.html -rwxrwsr-x 1 wagner m3 45843 2013-04-13 14:36 ./src_reports/m3poster.ps -rwxrwsr-x 1 wagner m3 44737 2013-04-13 14:36 ./src_reports/m3syntax.ps -rwxrwsr-x 1 wagner m3 31535 2013-04-13 14:36 ./src_reports/m3tokens.ps -r-xrwsr-x 1 wagner m3 235733 2013-04-13 14:36 ./src_reports/obliq.pdf -rwxrwsr-x 1 wagner m3 806862 2013-04-13 14:36 ./src_reports/obliq.ps -r-xrwsr-x 1 wagner m3 704201 2013-04-13 14:36 ./src_reports/src-068.pdf -rwxrwsr-x 1 wagner m3 2236519 2013-04-13 14:36 ./src_reports/src-068.ps -r-xrwsr-x 1 wagner m3 406003 2013-04-13 14:36 ./src_reports/src-069.pdf -r-xrwsr-x 1 wagner m3 554874 2013-04-13 14:36 ./src_reports/src-069.ps.gz -r-xrwsr-x 1 wagner m3 502259 2013-04-13 14:36 ./src_reports/src-113.pdf -rwxrwsr-x 1 wagner m3 487058 2013-04-13 14:36 ./src_reports/src-113.ps -r-xrwsr-x 1 wagner m3 261887 2013-04-13 14:36 ./src_reports/src-115.pdf -rwxrwsr-x 1 wagner m3 227121 2013-04-13 14:36 ./src_reports/src-115.ps -r-xrwsr-x 1 wagner m3 609326 2013-04-13 14:36 ./src_reports/vbtkit.pdf -rwxrwsr-x 1 wagner m3 734907 2013-04-13 14:36 ./src_reports/vbtkit.ps drwxrwsr-x 5 root m3 4096 2013-04-13 14:36 ./tutorial -rwxrwsr-x 1 wagner m3 2665 2013-04-13 14:36 ./tutorial/index.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/m3 -rwxrwsr-x 1 wagner m3 2081 2013-04-13 14:36 ./tutorial/m3/m3_10.html -rwxrwsr-x 1 wagner m3 1680 2013-04-13 14:36 ./tutorial/m3/m3_11.html -rwxrwsr-x 1 wagner m3 2312 2013-04-13 14:36 ./tutorial/m3/m3_12.html -rwxrwsr-x 1 wagner m3 1738 2013-04-13 14:36 ./tutorial/m3/m3_13.html -rwxrwsr-x 1 wagner m3 3033 2013-04-13 14:36 ./tutorial/m3/m3_14.html -rwxrwsr-x 1 wagner m3 1314 2013-04-13 14:36 ./tutorial/m3/m3_15.html -rwxrwsr-x 1 wagner m3 2327 2013-04-13 14:36 ./tutorial/m3/m3_16.html -rwxrwsr-x 1 wagner m3 2630 2013-04-13 14:36 ./tutorial/m3/m3_17.html -rwxrwsr-x 1 wagner m3 1989 2013-04-13 14:36 ./tutorial/m3/m3_18.html -rwxrwsr-x 1 wagner m3 1768 2013-04-13 14:36 ./tutorial/m3/m3_19.html -rwxrwsr-x 1 wagner m3 1636 2013-04-13 14:36 ./tutorial/m3/m3_1.html -rwxrwsr-x 1 wagner m3 4358 2013-04-13 14:36 ./tutorial/m3/m3_20.html -rwxrwsr-x 1 wagner m3 1273 2013-04-13 14:36 ./tutorial/m3/m3_21.html -rwxrwsr-x 1 wagner m3 1247 2013-04-13 14:36 ./tutorial/m3/m3_22.html -rwxrwsr-x 1 wagner m3 3723 2013-04-13 14:36 ./tutorial/m3/m3_23.html -rwxrwsr-x 1 wagner m3 1621 2013-04-13 14:36 ./tutorial/m3/m3_24.html -rwxrwsr-x 1 wagner m3 2050 2013-04-13 14:36 ./tutorial/m3/m3_25.html -rwxrwsr-x 1 wagner m3 1373 2013-04-13 14:36 ./tutorial/m3/m3_26.html -rwxrwsr-x 1 wagner m3 2068 2013-04-13 14:36 ./tutorial/m3/m3_27.html -rwxrwsr-x 1 wagner m3 1809 2013-04-13 14:36 ./tutorial/m3/m3_28.html -rwxrwsr-x 1 wagner m3 2698 2013-04-13 14:36 ./tutorial/m3/m3_29.html -rwxrwsr-x 1 wagner m3 1610 2013-04-13 14:36 ./tutorial/m3/m3_2.html -rwxrwsr-x 1 wagner m3 1261 2013-04-13 14:36 ./tutorial/m3/m3_30.html -rwxrwsr-x 1 wagner m3 1587 2013-04-13 14:36 ./tutorial/m3/m3_31.html -rwxrwsr-x 1 wagner m3 2271 2013-04-13 14:36 ./tutorial/m3/m3_32.html -rwxrwsr-x 1 wagner m3 1858 2013-04-13 14:36 ./tutorial/m3/m3_33.html -rwxrwsr-x 1 wagner m3 1665 2013-04-13 14:36 ./tutorial/m3/m3_34.html -rwxrwsr-x 1 wagner m3 2486 2013-04-13 14:36 ./tutorial/m3/m3_35.html -rwxrwsr-x 1 wagner m3 1389 2013-04-13 14:36 ./tutorial/m3/m3_36.html -rwxrwsr-x 1 wagner m3 1173 2013-04-13 14:36 ./tutorial/m3/m3_37.html -rwxrwsr-x 1 wagner m3 1600 2013-04-13 14:36 ./tutorial/m3/m3_38.html -rwxrwsr-x 1 wagner m3 1461 2013-04-13 14:36 ./tutorial/m3/m3_39.html -rwxrwsr-x 1 wagner m3 2051 2013-04-13 14:36 ./tutorial/m3/m3_3.html -rwxrwsr-x 1 wagner m3 1193 2013-04-13 14:36 ./tutorial/m3/m3_40.html -rwxrwsr-x 1 wagner m3 1719 2013-04-13 14:36 ./tutorial/m3/m3_41.html -rwxrwsr-x 1 wagner m3 1903 2013-04-13 14:36 ./tutorial/m3/m3_42.html -rwxrwsr-x 1 wagner m3 1530 2013-04-13 14:36 ./tutorial/m3/m3_43.html -rwxrwsr-x 1 wagner m3 1132 2013-04-13 14:36 ./tutorial/m3/m3_44.html -rwxrwsr-x 1 wagner m3 2410 2013-04-13 14:36 ./tutorial/m3/m3_45.html -rwxrwsr-x 1 wagner m3 1841 2013-04-13 14:36 ./tutorial/m3/m3_46.html -rwxrwsr-x 1 wagner m3 1575 2013-04-13 14:36 ./tutorial/m3/m3_47.html -rwxrwsr-x 1 wagner m3 3593 2013-04-13 14:36 ./tutorial/m3/m3_48.html -rwxrwsr-x 1 wagner m3 2928 2013-04-13 14:36 ./tutorial/m3/m3_49.html -rwxrwsr-x 1 wagner m3 1724 2013-04-13 14:36 ./tutorial/m3/m3_4.html -rwxrwsr-x 1 wagner m3 1766 2013-04-13 14:36 ./tutorial/m3/m3_50.html -rwxrwsr-x 1 wagner m3 2746 2013-04-13 14:36 ./tutorial/m3/m3_51.html -rwxrwsr-x 1 wagner m3 1558 2013-04-13 14:36 ./tutorial/m3/m3_52.html -rwxrwsr-x 1 wagner m3 1620 2013-04-13 14:36 ./tutorial/m3/m3_53.html -rwxrwsr-x 1 wagner m3 2907 2013-04-13 14:36 ./tutorial/m3/m3_54.html -rwxrwsr-x 1 wagner m3 1684 2013-04-13 14:36 ./tutorial/m3/m3_55.html -rwxrwsr-x 1 wagner m3 1812 2013-04-13 14:36 ./tutorial/m3/m3_56.html -rwxrwsr-x 1 wagner m3 1451 2013-04-13 14:36 ./tutorial/m3/m3_57.html -rwxrwsr-x 1 wagner m3 1126 2013-04-13 14:36 ./tutorial/m3/m3_58.html -rwxrwsr-x 1 wagner m3 1415 2013-04-13 14:36 ./tutorial/m3/m3_59.html -rwxrwsr-x 1 wagner m3 3899 2013-04-13 14:36 ./tutorial/m3/m3_5.html -rwxrwsr-x 1 wagner m3 2402 2013-04-13 14:36 ./tutorial/m3/m3_60.html -rwxrwsr-x 1 wagner m3 2352 2013-04-13 14:36 ./tutorial/m3/m3_61.html -rwxrwsr-x 1 wagner m3 1365 2013-04-13 14:36 ./tutorial/m3/m3_62.html -rwxrwsr-x 1 wagner m3 1265 2013-04-13 14:36 ./tutorial/m3/m3_63.html -rwxrwsr-x 1 wagner m3 1309 2013-04-13 14:36 ./tutorial/m3/m3_64.html -rwxrwsr-x 1 wagner m3 3073 2013-04-13 14:36 ./tutorial/m3/m3_65.html -rwxrwsr-x 1 wagner m3 3531 2013-04-13 14:36 ./tutorial/m3/m3_66.html -rwxrwsr-x 1 wagner m3 2757 2013-04-13 14:36 ./tutorial/m3/m3_67.html -rwxrwsr-x 1 wagner m3 2660 2013-04-13 14:36 ./tutorial/m3/m3_68.html -rwxrwsr-x 1 wagner m3 2392 2013-04-13 14:36 ./tutorial/m3/m3_69.html -rwxrwsr-x 1 wagner m3 3239 2013-04-13 14:36 ./tutorial/m3/m3_6.html -rwxrwsr-x 1 wagner m3 2165 2013-04-13 14:36 ./tutorial/m3/m3_70.html -rwxrwsr-x 1 wagner m3 1233 2013-04-13 14:36 ./tutorial/m3/m3_71.html -rwxrwsr-x 1 wagner m3 1931 2013-04-13 14:36 ./tutorial/m3/m3_72.html -rwxrwsr-x 1 wagner m3 1453 2013-04-13 14:36 ./tutorial/m3/m3_73.html -rwxrwsr-x 1 wagner m3 2133 2013-04-13 14:36 ./tutorial/m3/m3_74.html -rwxrwsr-x 1 wagner m3 1721 2013-04-13 14:36 ./tutorial/m3/m3_75.html -rwxrwsr-x 1 wagner m3 3972 2013-04-13 14:36 ./tutorial/m3/m3_76.html -rwxrwsr-x 1 wagner m3 5170 2013-04-13 14:36 ./tutorial/m3/m3_77.html -rwxrwsr-x 1 wagner m3 1640 2013-04-13 14:36 ./tutorial/m3/m3_78.html -rwxrwsr-x 1 wagner m3 3608 2013-04-13 14:36 ./tutorial/m3/m3_79.html -rwxrwsr-x 1 wagner m3 1352 2013-04-13 14:36 ./tutorial/m3/m3_7.html -rwxrwsr-x 1 wagner m3 1176 2013-04-13 14:36 ./tutorial/m3/m3_80.html -rwxrwsr-x 1 wagner m3 1390 2013-04-13 14:36 ./tutorial/m3/m3_81.html -rwxrwsr-x 1 wagner m3 1319 2013-04-13 14:36 ./tutorial/m3/m3_82.html -rwxrwsr-x 1 wagner m3 3127 2013-04-13 14:36 ./tutorial/m3/m3_83.html -rwxrwsr-x 1 wagner m3 1932 2013-04-13 14:36 ./tutorial/m3/m3_8.html -rwxrwsr-x 1 wagner m3 2028 2013-04-13 14:36 ./tutorial/m3/m3_9.html -rwxrwsr-x 1 wagner m3 39575 2013-04-13 14:36 ./tutorial/m3/m3_toc.html -rwxrwsr-x 1 wagner m3 37257 2013-04-13 14:36 ./tutorial/m3/old-index.html drwxrwsr-x 33 root m3 4096 2013-04-13 14:36 ./tutorial/ui drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/browser -rwxrwsr-x 1 wagner m3 2995 2013-04-13 14:36 ./tutorial/ui/browser/tut-browser.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/checkbox -rwxrwsr-x 1 wagner m3 2623 2013-04-13 14:36 ./tutorial/ui/checkbox/tut-checkbox.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/common -rwxrwsr-x 1 wagner m3 1658 2013-04-13 14:36 ./tutorial/ui/common/tut-common.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/confirm -rwxrwsr-x 1 wagner m3 600 2013-04-13 14:36 ./tutorial/ui/confirm/ConfirmVBT.i3 -rwxrwsr-x 1 wagner m3 1514 2013-04-13 14:36 ./tutorial/ui/confirm/ConfirmVBT.m3 -rwxrwsr-x 1 wagner m3 2751 2013-04-13 14:36 ./tutorial/ui/confirm/tut-confirm.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/cross -rwxrwsr-x 1 wagner m3 26685 2013-04-13 14:36 ./tutorial/ui/cross/tut-cross.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/drag -rwxrwsr-x 1 wagner m3 2052 2013-04-13 14:36 ./tutorial/ui/drag/tut-drag.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/draw -rwxrwsr-x 1 wagner m3 2620 2013-04-13 14:36 ./tutorial/ui/draw/tut-draw.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/edit -rwxrwsr-x 1 wagner m3 2441 2013-04-13 14:36 ./tutorial/ui/edit/tut-edit.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/feedback -r-xrwsr-x 1 wagner m3 487 2013-04-13 14:36 ./tutorial/ui/feedback/feedback1.gif -r-xrwsr-x 1 wagner m3 487 2013-04-13 14:36 ./tutorial/ui/feedback/feedback2.gif -r-xrwsr-x 1 wagner m3 598 2013-04-13 14:36 ./tutorial/ui/feedback/feedback3.gif -rwxrwsr-x 1 wagner m3 2175 2013-04-13 14:36 ./tutorial/ui/feedback/tut-feedback.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/hello -rwxrwsr-x 1 wagner m3 2515 2013-04-13 14:36 ./tutorial/ui/hello/tut-hello.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/intro -rwxrwsr-x 1 wagner m3 2319 2013-04-13 14:36 ./tutorial/ui/intro/tut-intro.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/key -rwxrwsr-x 1 wagner m3 2689 2013-04-13 14:36 ./tutorial/ui/key/tut-key.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/list -rwxrwsr-x 1 wagner m3 3206 2013-04-13 14:36 ./tutorial/ui/list/tut-list.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/menu1 -rwxrwsr-x 1 wagner m3 3285 2013-04-13 14:36 ./tutorial/ui/menu1/tut-menu1.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/menu2 -rwxrwsr-x 1 wagner m3 2540 2013-04-13 14:36 ./tutorial/ui/menu2/tut-menu2.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/mouse -rwxrwsr-x 1 wagner m3 1296 2013-04-13 14:36 ./tutorial/ui/mouse/Event.m3-sep -rwxrwsr-x 1 wagner m3 1922 2013-04-13 14:36 ./tutorial/ui/mouse/Mouse.m3-elided -rwxrwsr-x 1 wagner m3 2975 2013-04-13 14:36 ./tutorial/ui/mouse/tut-mouse.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/numeric -rwxrwsr-x 1 wagner m3 3157 2013-04-13 14:36 ./tutorial/ui/numeric/tut-numeric.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/overlap -rwxrwsr-x 1 wagner m3 2437 2013-04-13 14:36 ./tutorial/ui/overlap/tut-overlap.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/overlay -rwxrwsr-x 1 wagner m3 2126 2013-04-13 14:36 ./tutorial/ui/overlay/tut-overlay.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/push -rwxrwsr-x 1 wagner m3 3235 2013-04-13 14:36 ./tutorial/ui/push/tut-push.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/radio -rwxrwsr-x 1 wagner m3 1716 2013-04-13 14:36 ./tutorial/ui/radio/RadioButtons.m3 -rwxrwsr-x 1 wagner m3 1898 2013-04-13 14:36 ./tutorial/ui/radio/tut-radio.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/react -rwxrwsr-x 1 wagner m3 2636 2013-04-13 14:36 ./tutorial/ui/react/tut-react.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/rubber -rwxrwsr-x 1 wagner m3 4110 2013-04-13 14:36 ./tutorial/ui/rubber/tut-rubber.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/script -rwxrwsr-x 1 wagner m3 63 2013-04-13 14:36 ./tutorial/ui/script/m3makefile -rwxrwsr-x 1 wagner m3 1377 2013-04-13 14:36 ./tutorial/ui/script/tut-script.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/scroll -rwxrwsr-x 1 wagner m3 2516 2013-04-13 14:36 ./tutorial/ui/scroll/tut-scroll.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/shadow -rwxrwsr-x 1 wagner m3 2646 2013-04-13 14:36 ./tutorial/ui/shadow/tut-shadow.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/source -rwxrwsr-x 1 wagner m3 2374 2013-04-13 14:36 ./tutorial/ui/source/tut-source.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/switches -r-xrwsr-x 1 wagner m3 1370 2013-04-13 14:36 ./tutorial/ui/switches/switches1.gif -r-xrwsr-x 1 wagner m3 1385 2013-04-13 14:36 ./tutorial/ui/switches/switches2.gif -r-xrwsr-x 1 wagner m3 1553 2013-04-13 14:36 ./tutorial/ui/switches/switches3.gif -r-xrwsr-x 1 wagner m3 1601 2013-04-13 14:36 ./tutorial/ui/switches/switches4.gif -rwxrwsr-x 1 wagner m3 2821 2013-04-13 14:36 ./tutorial/ui/switches/tut-switches.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/text -rwxrwxr-x 1 wagner m3 3234 2013-04-13 14:36 ./tutorial/ui/text/tut-text.html -rwxrwsr-x 1 wagner m3 3199 2013-04-13 14:36 ./tutorial/ui/tutorial.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/update -rwxrwsr-x 1 wagner m3 2604 2013-04-13 14:36 ./tutorial/ui/update/tut-update.html -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Apr 13 17:48:09 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 13 Apr 2013 11:48:09 -0400 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: References: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Message-ID: <20130413154809.GB31583@topoi.pooq.com> On Sat, Apr 13, 2013 at 02:44:40AM +0000, Jay K wrote: > > Very old compilers don't support passing structs by value? THose would be very okd indeed. I know it wasn't available in the early 70's. But I don't think anyone is running Unix on a PDP-11 any more. I don't remember any more recent C compilers that don't pass strutures by value. Does anyone else? > > Third question that has been bugging me. > The C backend can output #line directives. > So you step through the Modula-3 source. What people expect. > This was working, and probably still does. > I turned it off subject to a constant in the backend. > Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) > > This is great for, during backend development/debugging, the C compiler gives me C line numbers. > If the backend worked perfectly, this would be pointless. > I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. > There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. > > > What to do to cater to both/everyone? > I wish I could have multiple #line directives: > #line 123 foo.m3.c 456 foo.m3 > > > but that doesn't exit. > I could encode information in the file name: > #line 123 "foo.m3.c/456 foo.m3" > > > but that is imperfect; error messages will be good, but debugging won't work > > > I could leave it as an #ifdef in the code. > I do not believe the following works: > #ifndef CLINE > #define LINE(cline, cfile, m3line, m3file) cline cfile > #else > #define LINE(cline, cfile, m3line, m3file) m3line m3file > #endif > #line LINE(123, "foo.c", 456, "foo.m3") > > > but I'll try it. > > > I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: > #ifndef CLINE > #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) > #endif > > This is bloated, but might be best. > > > if "#define LINE" works, great, but I doubt it will. If it works, it's likely to fail on C compilers that are a lot younger than PDP-11 Unix. But it's a lovely idea. > > > --- typeindex besides typeid? --- > > > I'm now doing a lot of lookups of typeids. > It'd be super nice if the frontend also maintained "small" incrementing > typeIndices that I could use to index into an array. > > > set_type_count(typeCount:CARDINAL); (* maybe *) > declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); That would need the front end to know how many types there would be before it can generate the typeCount. But if the typeCount were to be considered an estimate, or not available at all, the back end could reaallocate the typeindex-indexed array when necessary (or use some array-of-arrays data structure for growing arrays, to reduce copying on reallocation). You'd get almost the same performance, and obviate placinng a constraint on all future front-ends. (Yes, I'm still dreaming of a GPL2-compatible front end someday). > > > and thereafter, use typeIndex instead of typeId, an index into an array. > From hendrik at topoi.pooq.com Sat Apr 13 17:52:01 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 13 Apr 2013 11:52:01 -0400 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: References: <516825ED.9010003@lcwb.coop> Message-ID: <20130413155201.GC31583@topoi.pooq.com> On Sat, Apr 13, 2013 at 08:52:28AM +0200, Dragi?a Duri? wrote: > Never ending story :). > > To make it short - let's move to git! :) I do wish Linus hadn't rejected monotone. I find it much easier to use. > On Apr 12, 2013, at 5:33 PM, Jay K wrote: > > > CVS is awful. Even svn is now considered obsolete, let alone cvs. -- hendrik From rodney_bates at lcwb.coop Sun Apr 14 17:18:15 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 14 Apr 2013 10:18:15 -0500 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: References: <516825ED.9010003@lcwb.coop> Message-ID: <516AC8B7.2030807@lcwb.coop> Thanks. This appears to have worked. On 04/12/2013 10:33 AM, Jay K wrote: > CVS is awful. > Try this: > make sure you have "everything" "backed up" esp. m3-defn-complete.pdf > rm -rf the local directory with m3-defn-complete.pdf (that you backed up) > cvs upd -dAP to get it back > if m3-defn-complete.pdf is there > { > rm m3-defn-complete.pdf > cvs delete m3-defn-complete.pdf > cvs commit m3-defn-complete.pdf > } > copy in your new m3-defn-complete.pdf > cvs add m3-defn-complete.pdf > cvs commit m3-defn-complete.pdf > > - Jay > > > > > Date: Fri, 12 Apr 2013 10:19:09 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] Another CVS problem: adding a new file > > > > m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. > > cvs checkout says: > > > > cvs server: cannot find module `m3-defn-complete.pdf' - ignored > > > > When I try to add it, cvs add says: > > > > cvs add: `m3-defn-complete.pdf' added independently by second party > > > > and when I try to commit, cvs says: > > > > cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' > > cvs [commit aborted]: correct above errors first! > > From dragisha at m3w.org Mon Apr 15 09:22:29 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 15 Apr 2013 09:22:29 +0200 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <20130413155201.GC31583@topoi.pooq.com> References: <516825ED.9010003@lcwb.coop> <20130413155201.GC31583@topoi.pooq.com> Message-ID: <5C4A22D4-1CCA-4B67-86B1-E120721875A8@m3w.org> As we are witnessess in this thread, every system has its quirks, and there is no system without need-to-learn. So does cvs, and svn and git? But they are all alive and kicking, and monotone looks like it is not. So, git for cm3 it is? :) On Apr 13, 2013, at 5:52 PM, Hendrik Boom wrote: > I do wish Linus hadn't rejected monotone. I find it much easier to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Apr 15 09:30:29 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 15 Apr 2013 09:30:29 +0200 Subject: [M3devel] cvsup client, lots of SetAttrs and slow shutdown Message-ID: <886D7CC9-6ACE-48B6-8EF2-193D1EDE44A0@m3w.org> ? SetAttrs cm3/caltech-parser/term/src/Term.i3,v SetAttrs cm3/caltech-parser/term/src/Term.m3,v SetAttrs cm3/caltech-parser/term/src/TermC.c,v SetAttrs cm3/caltech-parser/term/src/TermC.h,v SetAttrs cm3/caltech-parser/term/src/TermC.i3,v SetAttrs cm3/caltech-parser/term/src/TermIO.i3,v SetAttrs cm3/caltech-parser/term/src/TermIO.m3,v SetAttrs cm3/caltech-parser/term/src/Termios.c,v ? Shutting down connection to server ?and waitinggggg Why does this happen? TIA, dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Tue Apr 16 03:28:16 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: <20130416012125.2CB685DEB25@birch.elegosoft.com> References: <20130416012125.2CB685DEB25@birch.elegosoft.com> Message-ID: It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 09:29:48 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 09:29:48 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) Message-ID: <3120B9A9-6804-4F51-83F7-B4F7DF0B9756@m3w.org> At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rcolebur at SCIRES.COM Tue Apr 16 18:34:45 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 16 Apr 2013 16:34:45 +0000 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Dragi?a : I notice that your tar.gz contains 4 files whose name differs only by case of letters: 1. libevent/src/BufferEvent.i3 2. libevent/src/BufferEvent.m3 3. libevent/src/bufferevent.i3 4. libevent/src/bufferevent.m3 On computers where the case of filenames is not significant, 2 of these files will be lost. This is the case on Windows. --Randy Coleburn From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Tuesday, April 16, 2013 3:30 AM To: m3devel Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 16 18:48:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Apr 2013 16:48:05 +0000 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Yes and no.Agreed one must avoid these constructs, file names that differ only in case. It is filesystems not operating systems that are generally case sensitive or case insensitive, though it is even more complicated than that. Consider networked file systems.All of ext3, HFS+, NTFS, FAT, and more are usable on Windows, MacOSX, and Linux/Unix. I believe ext3 is always case sensitive, FAT is always case insensitive, HFS+ I think it is an option at format time, and NTFS gets passed a flag as to case sensitivity for every file open call (and the upcase table is stored on disk at format time, in order to be stable for the entire life of the volume independent of what version of what operating system is operating on it) (er..the flag is by virtue of the NT kernel, so many file systems get the flag, but I assume some ignore it, and NTFS can be used on Linux and MacOSX and I don't know if such a flag exists there.) - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 16:34:45 +0000 Subject: Re: [M3devel] m3 libevent binding + objectification, pre-pre-release :) Dragi?a : I notice that your tar.gz contains 4 files whose name differs only by case of letters: 1. libevent/src/BufferEvent.i3 2. libevent/src/BufferEvent.m3 3. libevent/src/bufferevent.i3 4. libevent/src/bufferevent.m3 On computers where the case of filenames is not significant, 2 of these files will be lost. This is the case on Windows. --Randy Coleburn From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Tuesday, April 16, 2013 3:30 AM To: m3devel Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 19:01:51 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 19:01:51 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Thanks, I will fix it and resend. On Apr 16, 2013, at 6:34 PM, Coleburn, Randy wrote: > Dragi?a : > > I notice that your tar.gz contains 4 files whose name differs only by case of letters: > 1. libevent/src/BufferEvent.i3 > 2. libevent/src/BufferEvent.m3 > 3. libevent/src/bufferevent.i3 > 4. libevent/src/bufferevent.m3 > > On computers where the case of filenames is not significant, 2 of these files will be lost. > This is the case on Windows. > > --Randy Coleburn > > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Tuesday, April 16, 2013 3:30 AM > To: m3devel > Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) > > At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. > > I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). > -- > Dragi?a Duri? > dragisha at m3w.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 19:04:35 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 19:04:35 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <11121DBF-4C43-43AA-8574-DD40D15E8916@m3w.org> There is also a case of Dropbox? It is case insensitive. On Apr 16, 2013, at 6:48 PM, Jay K wrote: > Consider networked file systems. > All of ext3, HFS+, NTFS, FAT, and more are usable on Windows, MacOSX, and Linux/Unix. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 19:16:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 19:16:28 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: -- Dragi?a Duri? dragisha at m3w.org https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11743.tar.gz Here it is. On Apr 16, 2013, at 7:01 PM, Dragi?a Duri? wrote: > Thanks, I will fix it and resend. > > On Apr 16, 2013, at 6:34 PM, Coleburn, Randy wrote: > >> Dragi?a : >> >> I notice that your tar.gz contains 4 files whose name differs only by case of letters: >> 1. libevent/src/BufferEvent.i3 >> 2. libevent/src/BufferEvent.m3 >> 3. libevent/src/bufferevent.i3 >> 4. libevent/src/bufferevent.m3 >> >> On computers where the case of filenames is not significant, 2 of these files will be lost. >> This is the case on Windows. >> >> --Randy Coleburn >> >> From: Dragi?a Duri? [mailto:dragisha at m3w.org] >> Sent: Tuesday, April 16, 2013 3:30 AM >> To: m3devel >> Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) >> >> At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. >> >> I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torsten.kirschner at gmail.com Tue Apr 16 07:32:15 2013 From: torsten.kirschner at gmail.com (Torsten Kirschner) Date: Tue, 16 Apr 2013 07:32:15 +0200 Subject: [M3devel] new release In-Reply-To: <20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> <51126B00.7010301@columbus.rr.com> <20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> Message-ID: On Wed, Feb 6, 2013 at 4:38 PM, Olaf Wagner wrote: > ... > > Well, I think we will do a new release as soon as the C backend has > settled. > But you can always get current snapshots of the system from the Hudson > builds, at least for Linux and FreeBSD, see > > http://www.opencm3.net/snaps/snapshot-index.html > > I am amazed to see that SOLsun for Solaris 2.10 is a target. However, http://www.opencm3.net/snaps/cm3-bin-core-SOLsun-d5.9.0-sparc-sun-solaris2.10-2013-04-16-01-56-00.tgzseems to be the only link on that page that does not work. Coincidence, or is it part of a larger plan? ;-) best regards T -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Tue Apr 16 21:42:40 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Tue, 16 Apr 2013 21:42:40 +0200 Subject: [M3devel] new release In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL><00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu><51126B00.7010301@columbus.rr.com><20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> Message-ID: ...at least for Linux and FreeBSD,... and for Windows nobody cares even a bit! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 04:37:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 02:37:15 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, Message-ID: Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 04:32:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, Message-ID: Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 04:47:47 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 02:47:47 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, , , Message-ID: In the frontend, when pop_struct is called, is that too late to declare_record? To compile the type, is it? #0 M3CG_MultiPass__pop_struct (self_L_1033=0x101551758 "", m3_typeid_L_1034=1557134085, byte_size_L_1035=8, alignment_L_1036=8) at M3CG_MultiPass.m3.c:38639 #1 0x000000010044718a in M3CG_Check__pop_struct (self_L_369=0x1015525b8, t_L_370=1557134085, s_L_371=8, a_L_372=8) at M3CG_Check.m3.c:34613 #2 0x000000010024a584 in CG__Pop_struct (t_L_578=1557134085, s_L_579=64, a_L_580=64) at CG.m3.c:83537 #3 0x00000001002ddcd7 in Formal__EmitArg (proc_L_215=0x10151e4c8 "??h", formal_L_216=0x10151c7a0 "?Bj", actual_L_217=0x10151c758 "??h") at Formal.m3.c:15818 #4 0x00000001002c3aa7 in UserProc (ce_L_148=0x10151e540 "@\034\020\001\001") at UserProc.m3.c:5026 #5 0x000000010019b893 in CallExpr (p_L_149=0x10151e540 "@\034\020\001\001") at CallExpr.m3.c:12276 #6 0x0000000100186765 in Expr (t_L_126=0x10151e540 "@\034\020\001\001") at Expr.m3.c:4085 #7 0x000000010025a70f in CallStmt__Compile (p_L_36=0x10151e598) at CallStmt.m3.c:1411 #8 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e598 "??i") at Stmt.m3.c:2881 #9 0x0000000100259e79 in BlockStmt__Compile (p_L_69=0x10151e320) at BlockStmt.m3.c:4642 #10 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e320 "?i") at Stmt.m3.c:2881 #11 0x00000001002f35b5 in Procedure__GenBody (p_L_318=0x10151e0b0 "?`j") at Procedure.m3.c:21223 #12 0x00000001002f38ec in Procedure__EmitBody (x_L_310=0x10151e268) at Procedure.m3.c:19937 #13 0x00000001002275b3 in ProcBody__EmitBody (t_L_64=0x10151e268 "?\030\020\001\001") at ProcBody.m3.c:6940 #14 0x000000010022794d in ProcBody__EmitAll (proc_info_L_56=0x7fff5fbfdeb8) at ProcBody.m3.c:2822 #15 0x00000001002e73d6 in Module__CompileModule (t_L_379=0x101512fe0 "?Xj") at Module.m3.c:25364 #16 0x00000001002eafe8 in Module__Compile (t_L_283=0x101512fe0 "?Xj") at Module.m3.c:23264 #17 0x00000001001f78df in M3Front__DoCompile () at M3Front.m3.c:7176 #18 0x00000001001f8391 in M3Front__Compile (input_L_88=0x7fff5fbfe150, env_L_89=0x1013910a8, options_L_90=0x101355840) at M3Front.m3.c:3827 #19 0x0000000100021886 in Builder__RunM3 (s_L_494=0x10136fdb0, u_L_495=0x1012df768, object_L_496=0x1013557a0 "??n") at Builder.m3.c:56168 #20 0x0000000100022bac in Builder__PushOneM3 (s_L_444=0x10136fdb0, u_L_445=0x1012df768) at Builder.m3.c:48299 #21 0x0000000100023cb5 in Builder__CompileM3 (s_L_423=0x10136fdb0, u_L_424=0x1012df768) at Builder.m3.c:45901 #22 0x000000010001ea71 in Builder__CompileOne (s_L_404=0x10136fdb0, u_L_405=0x1012df768) at Builder.m3.c - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: Re: [M3devel] frontend misses a few types Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 17 11:26:55 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 17 Apr 2013 11:26:55 +0200 Subject: [M3devel] cm3ide (/ m3browser?) references Message-ID: cm3ide does not parse procedure bodies for references, only signature elements are parsed/hyperlinked. Is there a way to get internal references parsed/hyperlinked - short of do-it-with-m3tk? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Wed Apr 17 18:06:11 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 16:06:11 +0000 Subject: [M3devel] cm3ide (/ m3browser?) references In-Reply-To: References: Message-ID: 1) I don't know. but 2) cm3ide I believe is consuming frontend output. jbook2:python jay$ ls /dev2/cm3/m3-sys/m3front/src/*/*Web* /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.i3 /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.m3 Likely nobody would object if you augmented this with more information. It looks like it is structured like putting in another backend, but one that doesn't get all the calls i.e. codegen like load/store/add/call. book2:python jay$ grep -i webinfo /dev2/cm3/m3-sys/m3front/src/*/*m3 /dev2/cm3/m3-sys/m3front/src/misc/CG.m3:IMPORT Scanner, Error, Module, RunTyme, WebInfo; /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Import_unit (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Export_unit (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_array (t, index, elt, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_open_array (t, elt, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_enum (t, n_elts, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_enum_elt (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_packed (t, s, base); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_record (t, s, n_fields); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_field (n, o, s, t); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_set (t, domain, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_subrange (t, domain, min, max, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_pointer (t, target, brand, traced); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_indirect (x, target); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_proctype (t, n_formals, result, n_raises); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_formal (n, t); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_raises (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_object (t, super, brand, traced, /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_method (n, signature, dfault); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_override (n, dfault); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_opaque (t, super); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Reveal_opaque (lhs, rhs); /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.m3:MODULE WebInfo; /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.m3:END WebInfo. /dev2/cm3/m3-sys/m3front/src/values/Module.m3:IMPORT Host, Token, Revelation, Coverage, Decl, Scanner, WebInfo; /dev2/cm3/m3-sys/m3front/src/values/Module.m3: WebInfo.Reset (); /dev2/cm3/m3-sys/m3front/src/values/Module.m3: Host.env.note_webinfo (WebInfo.Finish ()); /dev2/cm3/m3-sys/m3front/src/values/Tipe.m3:IMPORT M3, M3ID, CG, Value, ValueRep, Scope, OpaqueType, WebInfo; /dev2/cm3/m3-sys/m3front/src/values/Tipe.m3: WebInfo.Declare_typename (uid, t); I kind of wonder if it could be better structured by actually taking it out of m3front and layering like I have my multiple pass backend.. i.e. a multiplexing backend.. - Jay From: dragisha at m3w.org Date: Wed, 17 Apr 2013 11:26:55 +0200 To: m3devel at elegosoft.com Subject: [M3devel] cm3ide (/ m3browser?) references cm3ide does not parse procedure bodies for references, only signature elements are parsed/hyperlinked. Is there a way to get internal references parsed/hyperlinked - short of do-it-with-m3tk? --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 18:24:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 16:24:51 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, , , , , , Message-ID: ok, so this fixes it. I still have to build everything to verify. But which of the two lines is right? Both? And what about the comment about the assert? And what about other types like fixed size arrays? I'll try them. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/values/Formal.m3,v retrieving revision 1.18 diff -u -r1.18 Formal.m3 --- Formal.m3 26 Sep 2012 17:12:37 -0000 1.18 +++ Formal.m3 17 Apr 2013 16:23:29 -0000 @@ -600,6 +600,8 @@ PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) + Type.Compile (t.tipe); + Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) Type.Compile (t.tipe); Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); | Mode.mVAR => Expr.CompileAddress (actual, traced := TRUE); | Mode.mCONST => IF Expr.IsDesignator (actual) THEN Expr.CompileAddress (actual, traced := FALSE); ELSE Expr.Compile (actual); (* not needed because of the ASSERT above: GenCopy (t.tipe); *) END; END; END GenRecord; From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:47:47 +0000 Subject: Re: [M3devel] frontend misses a few types In the frontend, when pop_struct is called, is that too late to declare_record? To compile the type, is it? #0 M3CG_MultiPass__pop_struct (self_L_1033=0x101551758 "", m3_typeid_L_1034=1557134085, byte_size_L_1035=8, alignment_L_1036=8) at M3CG_MultiPass.m3.c:38639 #1 0x000000010044718a in M3CG_Check__pop_struct (self_L_369=0x1015525b8, t_L_370=1557134085, s_L_371=8, a_L_372=8) at M3CG_Check.m3.c:34613 #2 0x000000010024a584 in CG__Pop_struct (t_L_578=1557134085, s_L_579=64, a_L_580=64) at CG.m3.c:83537 #3 0x00000001002ddcd7 in Formal__EmitArg (proc_L_215=0x10151e4c8 "??h", formal_L_216=0x10151c7a0 "?Bj", actual_L_217=0x10151c758 "??h") at Formal.m3.c:15818 #4 0x00000001002c3aa7 in UserProc (ce_L_148=0x10151e540 "@\034\020\001\001") at UserProc.m3.c:5026 #5 0x000000010019b893 in CallExpr (p_L_149=0x10151e540 "@\034\020\001\001") at CallExpr.m3.c:12276 #6 0x0000000100186765 in Expr (t_L_126=0x10151e540 "@\034\020\001\001") at Expr.m3.c:4085 #7 0x000000010025a70f in CallStmt__Compile (p_L_36=0x10151e598) at CallStmt.m3.c:1411 #8 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e598 "??i") at Stmt.m3.c:2881 #9 0x0000000100259e79 in BlockStmt__Compile (p_L_69=0x10151e320) at BlockStmt.m3.c:4642 #10 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e320 "?i") at Stmt.m3.c:2881 #11 0x00000001002f35b5 in Procedure__GenBody (p_L_318=0x10151e0b0 "?`j") at Procedure.m3.c:21223 #12 0x00000001002f38ec in Procedure__EmitBody (x_L_310=0x10151e268) at Procedure.m3.c:19937 #13 0x00000001002275b3 in ProcBody__EmitBody (t_L_64=0x10151e268 "?\030\020\001\001") at ProcBody.m3.c:6940 #14 0x000000010022794d in ProcBody__EmitAll (proc_info_L_56=0x7fff5fbfdeb8) at ProcBody.m3.c:2822 #15 0x00000001002e73d6 in Module__CompileModule (t_L_379=0x101512fe0 "?Xj") at Module.m3.c:25364 #16 0x00000001002eafe8 in Module__Compile (t_L_283=0x101512fe0 "?Xj") at Module.m3.c:23264 #17 0x00000001001f78df in M3Front__DoCompile () at M3Front.m3.c:7176 #18 0x00000001001f8391 in M3Front__Compile (input_L_88=0x7fff5fbfe150, env_L_89=0x1013910a8, options_L_90=0x101355840) at M3Front.m3.c:3827 #19 0x0000000100021886 in Builder__RunM3 (s_L_494=0x10136fdb0, u_L_495=0x1012df768, object_L_496=0x1013557a0 "??n") at Builder.m3.c:56168 #20 0x0000000100022bac in Builder__PushOneM3 (s_L_444=0x10136fdb0, u_L_445=0x1012df768) at Builder.m3.c:48299 #21 0x0000000100023cb5 in Builder__CompileM3 (s_L_423=0x10136fdb0, u_L_424=0x1012df768) at Builder.m3.c:45901 #22 0x000000010001ea71 in Builder__CompileOne (s_L_404=0x10136fdb0, u_L_405=0x1012df768) at Builder.m3.c - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: Re: [M3devel] frontend misses a few types Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 17 20:01:11 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 17 Apr 2013 20:01:11 +0200 Subject: [M3devel] cm3ide (/ m3browser?) references In-Reply-To: References: Message-ID: <7FF88BD3-BBBA-4042-BC85-C7968365EC75@m3w.org> I am using WebInfo output for various RT info/layout data needed in program. But, .M3WEB does not contain token level information. Not even what can be seen in cm3ide. You are probably right on this, though? It would be easier to work through m3front, and decorate along the way. On Apr 17, 2013, at 6:06 PM, Jay K wrote: > 1) I don't know. > but > 2) cm3ide I believe is consuming frontend output. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Wed Apr 17 20:27:50 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 17 Apr 2013 18:27:50 +0000 Subject: [M3devel] cm3ide (/ m3browser?) references Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF0C28B793@ATLEX04-SRV.SCIRES.LOCAL> I suppose it would require someone modifying the code, perhaps incorporating elements of m3tk. The current cm3ide is basically a repackaged version of Critical Mass? Reactor, with changes to deal with removal of intellectual property rights belonging to Critical Mass, Inc. --Randy Coleburn From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Wednesday, April 17, 2013 5:27 AM To: m3devel Subject: EXT:[M3devel] cm3ide (/ m3browser?) references cm3ide does not parse procedure bodies for references, only signature elements are parsed/hyperlinked. Is there a way to get internal references parsed/hyperlinked - short of do-it-with-m3tk? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Apr 18 09:07:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 18 Apr 2013 09:07:06 +0200 Subject: [M3devel] cm3ide cpu usage Message-ID: <7B1D4CA8-5469-4095-BC7E-4B9902785198@m3w.org> It looks like cm3ide becomes very CPU hungry, after some time. It is probably an issue with not-detected EOF in TCP.T "channel" they use. Anybody else met this issue? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Fri Apr 19 06:24:19 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Apr 2013 04:24:19 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,,, , , , , , , , Message-ID: Here is a smaller fix that fixes more cases, i.e. large sets and fixed sized arrays. Index: values/Formal.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/values/Formal.m3,v retrieving revision 1.18 diff -u -r1.18 Formal.m3 --- values/Formal.m3 26 Sep 2012 17:12:37 -0000 1.18 +++ values/Formal.m3 19 Apr 2013 04:19:55 -0000 @@ -470,6 +470,7 @@ CG.Pop_param (CG.Type.Addr) ELSIF (is_struct) THEN EVAL Type.CheckInfo (t.tipe, info); + Type.Compile (t.tipe); CG.Pop_struct (Type.GlobalUID (t.tipe), info.size, info.alignment); ELSE (* by-value scalar *) CG.Pop_param (Type.CGType (t.tipe, in_memory := TRUE)); - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 16:24:51 +0000 Subject: Re: [M3devel] frontend misses a few types ok, so this fixes it. I still have to build everything to verify. But which of the two lines is right? Both? And what about the comment about the assert? And what about other types like fixed size arrays? I'll try them. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/values/Formal.m3,v retrieving revision 1.18 diff -u -r1.18 Formal.m3 --- Formal.m3 26 Sep 2012 17:12:37 -0000 1.18 +++ Formal.m3 17 Apr 2013 16:23:29 -0000 @@ -600,6 +600,8 @@ PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) + Type.Compile (t.tipe); + Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) Type.Compile (t.tipe); Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); | Mode.mVAR => Expr.CompileAddress (actual, traced := TRUE); | Mode.mCONST => IF Expr.IsDesignator (actual) THEN Expr.CompileAddress (actual, traced := FALSE); ELSE Expr.Compile (actual); (* not needed because of the ASSERT above: GenCopy (t.tipe); *) END; END; END GenRecord; From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:47:47 +0000 Subject: Re: [M3devel] frontend misses a few types In the frontend, when pop_struct is called, is that too late to declare_record? To compile the type, is it? #0 M3CG_MultiPass__pop_struct (self_L_1033=0x101551758 "", m3_typeid_L_1034=1557134085, byte_size_L_1035=8, alignment_L_1036=8) at M3CG_MultiPass.m3.c:38639 #1 0x000000010044718a in M3CG_Check__pop_struct (self_L_369=0x1015525b8, t_L_370=1557134085, s_L_371=8, a_L_372=8) at M3CG_Check.m3.c:34613 #2 0x000000010024a584 in CG__Pop_struct (t_L_578=1557134085, s_L_579=64, a_L_580=64) at CG.m3.c:83537 #3 0x00000001002ddcd7 in Formal__EmitArg (proc_L_215=0x10151e4c8 "??h", formal_L_216=0x10151c7a0 "?Bj", actual_L_217=0x10151c758 "??h") at Formal.m3.c:15818 #4 0x00000001002c3aa7 in UserProc (ce_L_148=0x10151e540 "@\034\020\001\001") at UserProc.m3.c:5026 #5 0x000000010019b893 in CallExpr (p_L_149=0x10151e540 "@\034\020\001\001") at CallExpr.m3.c:12276 #6 0x0000000100186765 in Expr (t_L_126=0x10151e540 "@\034\020\001\001") at Expr.m3.c:4085 #7 0x000000010025a70f in CallStmt__Compile (p_L_36=0x10151e598) at CallStmt.m3.c:1411 #8 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e598 "??i") at Stmt.m3.c:2881 #9 0x0000000100259e79 in BlockStmt__Compile (p_L_69=0x10151e320) at BlockStmt.m3.c:4642 #10 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e320 "?i") at Stmt.m3.c:2881 #11 0x00000001002f35b5 in Procedure__GenBody (p_L_318=0x10151e0b0 "?`j") at Procedure.m3.c:21223 #12 0x00000001002f38ec in Procedure__EmitBody (x_L_310=0x10151e268) at Procedure.m3.c:19937 #13 0x00000001002275b3 in ProcBody__EmitBody (t_L_64=0x10151e268 "?\030\020\001\001") at ProcBody.m3.c:6940 #14 0x000000010022794d in ProcBody__EmitAll (proc_info_L_56=0x7fff5fbfdeb8) at ProcBody.m3.c:2822 #15 0x00000001002e73d6 in Module__CompileModule (t_L_379=0x101512fe0 "?Xj") at Module.m3.c:25364 #16 0x00000001002eafe8 in Module__Compile (t_L_283=0x101512fe0 "?Xj") at Module.m3.c:23264 #17 0x00000001001f78df in M3Front__DoCompile () at M3Front.m3.c:7176 #18 0x00000001001f8391 in M3Front__Compile (input_L_88=0x7fff5fbfe150, env_L_89=0x1013910a8, options_L_90=0x101355840) at M3Front.m3.c:3827 #19 0x0000000100021886 in Builder__RunM3 (s_L_494=0x10136fdb0, u_L_495=0x1012df768, object_L_496=0x1013557a0 "??n") at Builder.m3.c:56168 #20 0x0000000100022bac in Builder__PushOneM3 (s_L_444=0x10136fdb0, u_L_445=0x1012df768) at Builder.m3.c:48299 #21 0x0000000100023cb5 in Builder__CompileM3 (s_L_423=0x10136fdb0, u_L_424=0x1012df768) at Builder.m3.c:45901 #22 0x000000010001ea71 in Builder__CompileOne (s_L_404=0x10136fdb0, u_L_405=0x1012df768) at Builder.m3.c - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: Re: [M3devel] frontend misses a few types Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 20 12:52:58 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 20 Apr 2013 12:52:58 +0200 Subject: [M3devel] "fork" Message-ID: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. My idea is basically to do this migration/fork without actually doing one. In short: * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. * Do all our work on SVN, * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. We can also use GIT in one of two scenarios: * Go straight from CVS to GIT, never look back; * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. Thanks for reading this! :) dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dragisha at m3w.org Sat Apr 20 14:15:56 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 20 Apr 2013 14:15:56 +0200 Subject: [M3devel] first tests, cvs2svn Message-ID: I did initial conversion, just to try it and see what happens. Initial size (CVS repo is: cca 2.1GB, Resulting size is: 661MB, tmp space used: under 600MB time used (on a core duo 2.4GHz box): as per table attached I had two collisions from Attic files, deleted them. Another problem was encoding ambiguity, solved it with additional switches. I am currently checking all of it out, and then I will compare it with a CVS full checkout. More on this in next post. dd ========================================== Command line: % cvs2svn -s ~/cm3-svn /opt/cm3-cvs --encoding=utf8 --fallback-encoding=latin1 Results: cvs2svn Statistics: ------------------ Total CVS Files: 57642 Total CVS Revisions: 159237 Total CVS Branches: 135634 Total CVS Tags: 1123784 Total Unique Tags: 963 Total Unique Branches: 16 CVS Repos Size in KB: 2069996 Total SVN Commits: 12228 First Revision Date: Sat Jan 13 15:15:12 2001 Last Revision Date: Thu Apr 18 18:24:28 2013 ------------------ Timings (seconds): ------------------ 292 pass1 CollectRevsPass 1 pass2 CleanMetadataPass 0 pass3 CollateSymbolsPass 514 pass4 FilterSymbolsPass 2 pass5 SortRevisionsPass 7 pass6 SortSymbolsPass 134 pass7 InitializeChangesetsPass 32 pass8 BreakRevisionChangesetCyclesPass 27 pass9 RevisionTopologicalSortPass 77 pass10 BreakSymbolChangesetCyclesPass 114 pass11 BreakAllChangesetCyclesPass 91 pass12 TopologicalSortPass 80 pass13 CreateRevsPass 22 pass14 SortSymbolOpeningsClosingsPass 4 pass15 IndexSymbolsPass 2050 pass16 OutputPass 3448 total -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hendrik at topoi.pooq.com Sat Apr 20 14:43:21 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 20 Apr 2013 08:43:21 -0400 Subject: [M3devel] "fork" In-Reply-To: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> Message-ID: <20130420124321.GA7844@topoi.pooq.com> On Sat, Apr 20, 2013 at 12:52:58PM +0200, Dragi?a Duri? wrote: > We have this situation where Elego does not have neither interest nor > resources to spare to do version control system migration. Projects > like GCC and GNOME have abandoned CVS for good, and they are only two > on a very long list. The main problem I see with this is that svn is still not a distributed version-control system. However, cvs2svn does seem to be a stepping-stone to most current distributed version-control systems, so it is a step in the right direction. -- hendrik From darko at darko.org Sat Apr 20 13:51:25 2013 From: darko at darko.org (Darko) Date: Sat, 20 Apr 2013 04:51:25 -0700 Subject: [M3devel] "fork" In-Reply-To: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> Message-ID: FWIW, I vote for a one way trip to GIT, to me it seems like far and away the best tool, probably because it is a clean break from CVS. Maybe we can host on GitHub or a similar service. Why do we need to maintain the existing CVS? I'm happy to donate a server if we need to move the build infrastructure as a result. On Apr 20, 2013, at 3:52 AM, Dragi?a Duri? wrote: > We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. > > My idea is basically to do this migration/fork without actually doing one. In short: > * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. > * Do all our work on SVN, > * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. > > This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. > > My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. > > We can also use GIT in one of two scenarios: > * Go straight from CVS to GIT, never look back; > * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. > > This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. > > I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. > > Thanks for reading this! :) > dd > > -- > Dragi?a Duri? > dragisha at m3w.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 20 19:52:52 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Apr 2013 17:52:52 +0000 Subject: [M3devel] struct pass and return, an additional mode? Message-ID: The frontend supports the following, Target.i3: results_on_left => when the front-end is passing structures the return result is the left-most parameter. Otherwise, it is the right-most parameter. standard_structs => TRUE => the front-end will take care of all structure passing: by VALUE parameters: callers pass the address of the structure and the callee copies it into a temporary. return results: the caller passes as the left-most or right-most parameter the address of the temporary that will hold the result and the callee copies the value there. FALSE => by VALUE parameters: the back-end is responsible. (ie. M3CG.T.Pop_struct will be called) return results: the caller passes as the left-most or right-most parameter the address of the temporary that will hold the result and the callee copies the value there. The start_call, call, and exit_proc methods are called with t=Struct. I want an additional mode. I want no extra parameter for struct return. My backend could easily pass and return them by value and hide the details. TYPE StructReturn = [None, Left, Right]; ? Too much is wrapped up in standard_structs -- pass and return could/should be separate. TYPE StructPass = [Value, Pointer]; ? I grant that really supporting this in the frontend might be a bit of work, and there might be little point, as the code is all rarely used. Maybe I should work on improving something else, e.g. scopes or global variables/segments. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 20 21:11:19 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 20 Apr 2013 21:11:19 +0200 Subject: [M3devel] "fork" In-Reply-To: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> Message-ID: <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> On Sat, 20 Apr 2013 12:52:58 +0200 Dragi?a Duri? wrote: > We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. > > My idea is basically to do this migration/fork without actually doing one. In short: > * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. > * Do all our work on SVN, > * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. > > This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. > > My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. > > We can also use GIT in one of two scenarios: > * Go straight from CVS to GIT, never look back; > * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. > > This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. > > I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. Indeed svn would be the easier way to go, but I'm not sure that is what most of the developers now want. In contrast to what I said two or three years ago, I now think that a migration away from CVS is overdue, but I haven't had the time to do it right and probably won't have that time in the near future. We _do_ have several svn and git experts in our company, but I haven't been able to inspire them to do the migration yet. Actually I think that the migration itself will be not very difficult; it is the Hudson/Jenkins/Apache/scripts support that will mostly need to be rewritten wrt. version control. I doubt that anybody outside of Elego has done much work on that. I'd like to try to acquire some internal ressources again; so I'd ask you to wait for some weeks. If I haven't been able to organize something until June, I'd think it will be best if someone else takes over completely. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sat Apr 20 21:51:10 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 20 Apr 2013 21:51:10 +0200 Subject: [M3devel] "fork" In-Reply-To: <20130420185340.GA5483@zoho.com> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420185340.GA5483@zoho.com> Message-ID: <64E848A5-4EAE-45D8-B116-A780741F25E9@m3w.org> Also monotone, Bazaar, mercurial? :) From fossil-users mailing list: > > Please guide me how do I convert CVS repository to fossil, > > preserving history and branches / tags. > > There is no generalized procedure for doing this. To convert SQLite > from CVS to fossil, I wrote a TCL script that checked out each > historical version of of SQL from CVS then checked it back into > fossil. It took several hours to run. I don't know where you got this information on "Linux only"? See http://git-scm.com/downloads If someone has better proposal, then please respond. -- Dragi?a Duri? dragisha at m3w.org On Apr 20, 2013, at 8:53 PM, microcode at zoho.com wrote: > Hi, what about fossi? (fossil-scm.org). It has a lot of nice features, > builds anywhere (unlike GIT which is hell to build anywhere but Linux) and > is from the author of SQLite- code is small and dead simple. > > > On Sat, Apr 20, 2013 at 12:52:58PM +0200, Dragi??a Duri?? wrote: >> We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. >> >> My idea is basically to do this migration/fork without actually doing one. In short: >> * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. >> * Do all our work on SVN, >> * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. >> >> This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. >> >> My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. >> >> We can also use GIT in one of two scenarios: >> * Go straight from CVS to GIT, never look back; >> * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. >> >> This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. >> >> I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. >> >> Thanks for reading this! :) >> dd >> >> -- >> Dragi??a Duri?? >> dragisha at m3w.org >> >> >> > > > > -- > _ _ > ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___ > | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._> > |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Apr 21 07:33:05 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Apr 2013 07:33:05 +0200 Subject: [M3devel] "fork" In-Reply-To: <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> Message-ID: <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> Well, this changes situation :). If nobody insists on CVS, then single jump from CVS to GIT is all we need. -- Dragi?a Duri? dragisha at m3w.org On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: > In contrast to what I said two or three years ago, I now think that > a migration away from CVS is overdue, but I haven't had the time to do it > right and probably won't have that time in the near future. We _do_ have > several svn and git experts in our company, but I haven't been able > to inspire them to do the migration yet. > > Actually I think that the migration itself will be not very difficult; it is > the Hudson/Jenkins/Apache/scripts support that will mostly need to be > rewritten wrt. version control. I doubt that anybody outside of Elego has > done much work on that. > > I'd like to try to acquire some internal ressources again; so I'd ask > you to wait for some weeks. If I haven't been able to organize something > until June, I'd think it will be best if someone else takes over completely. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Sun Apr 21 07:54:53 2013 From: peter.mckinna at gmail.com (Peter McKinna) Date: Sun, 21 Apr 2013 15:54:53 +1000 Subject: [M3devel] "fork" In-Reply-To: <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> Message-ID: Hi, I too support a clean move to git Great tool-set, very fast. The swig guys recently did a similar move to git, hosting it on github and all went very smoothly. Regards Peter On Sun, Apr 21, 2013 at 3:33 PM, Dragi?a Duri? wrote: > Well, this changes situation :). If nobody insists on CVS, then single > jump from CVS to GIT is all we need. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: > > In contrast to what I said two or three years ago, I now think that > a migration away from CVS is overdue, but I haven't had the time to do it > right and probably won't have that time in the near future. We _do_ have > several svn and git experts in our company, but I haven't been able > to inspire them to do the migration yet. > > Actually I think that the migration itself will be not very difficult; it > is > the Hudson/Jenkins/Apache/scripts support that will mostly need to be > rewritten wrt. version control. I doubt that anybody outside of Elego has > done much work on that. > > I'd like to try to acquire some internal ressources again; so I'd ask > you to wait for some weeks. If I haven't been able to organize something > until June, I'd think it will be best if someone else takes over > completely. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Apr 21 17:29:17 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Apr 2013 17:29:17 +0200 Subject: [M3devel] backend issues wrt garbage collection Message-ID: <4EB7E3F6-4D2A-4C0C-957A-49F813F60ABB@m3w.org> LLVM has a notion of a stacklet. So, stack is - possibly - non contiguous and as such it is not compatible with current GC. Fixable, but still an issue. Also, with C/C++ being a planned/developed backend, two issues emerge. One is - are global variables per module kept in contiguous space per module? Another is - what is compiler/backend/ABI/whatever of this final C/C++ compiler step and what it's stack is like? :) Also, are those global variable spaces kept contiguous regardless of optimizations? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dragisha at m3w.org Sun Apr 21 22:19:41 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Apr 2013 22:19:41 +0200 Subject: [M3devel] Trial conversion(s) Message-ID: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. Report tomorrow, or so :) -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Sun Apr 21 22:55:43 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Apr 2013 20:55:43 +0000 Subject: [M3devel] null type? Message-ID: What is the meaning of this: cm3/elego/graphicutils/src/RsrcFilter init(p1, p2, p3, p4, p5, p6 := NIL) : T; (* Initializes the resource search path. *) PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = What are the types of p1, p2, etc.? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 21 23:12:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Apr 2013 21:12:04 +0000 Subject: [M3devel] backend issues wrt garbage collection In-Reply-To: <4EB7E3F6-4D2A-4C0C-957A-49F813F60ABB@m3w.org> References: <4EB7E3F6-4D2A-4C0C-957A-49F813F60ABB@m3w.org> Message-ID: 1) Stack can/should be assumed contiguous. We don't handle IA64's two stacks properly though -- they grow up and down from same location. The one that grows up is for register spills. 2) It is very real. It has been working for months, building the entire system. Our Modula-3 implementation is perhaps "surprising". >From a certain point of view. There are two special structs per module, refered to as "segments", that contain the global read only data and global writable data. I would like to fix/change this at some point. There are significant disadvantages in the current scheme, and there are possible advantages, and reasons it is hard to change/fix. The disadvantages: none of the fields in the segments are named; it is highly non-debuggable. references to globals are via offsets -- the frontend has done the layout; fixing it, making them either named or separate variables, will require frontend work. For non-garbage collected data, I really don't see the point. For garbage collected data, there might be offsets recorded in yet more places. This either have to be preserved, or the offsets changed to pointers. There are advantages/disadvantages either way. Offsets can usually be smaller, e.g. only 32 bits on a 64bit target, and offsets imply an efficiency in the executable file and loading it -- i.e. fewer relocs or less indirection for position independent code. But ignoring those points and thinking from an idealized C point of view, separate data and pointers would be nice. Furthermore, separate variables give us a chance the compiler/linker can throw out unused data. However, the model here actually resembles what C compilers are forced to usually do anyway. Specifically, in a .c/.cpp file, you will generally get all the read only data linked in, or none of it, and all the writable data, or none of it. Linkers do NOT generally strip unused data. Given the code: int i; void *p = &foo; void foo() { } if "i" is referenced outside the file, then p and foo will be linked in as well, even if they are not otherwise used. In Microsoft Visual C++ you can do a bit better. You can mark constant ininitialized data as "__declspec(selectany)". The direct implied meaning is one thing, but the indirect meaning includes that it will be dead-stripped -- only linked in if referenced. I don't know how to do this with other compilers. The point is, these Modula-3 "segments" seem to closely emulate what most?all C compilers do anyway. But, they do it in a way that is guaranteed to be this way, even if some C compilers are different. However, I don't really see value in this approach. For C and C++ I think it is mostly subtle and unknown to programmers and causes the linker to bring in more code/data than is needed/expected. However, I expect it is also impossible to change without breaking some programs that depend on it. For Modula-3, I'm less worried about the changed semantics. Point being, if/when we separate out globals from "segments", I would be inclined to mark all the constants as __declspec(selectany), unless we know something further up the chain won't ever output unused data. We might also be able to win by using #pragma segment, a different segment for each data. > One is - are global variables per module kept in contiguous space per module? Yes. Two separate segments, for constants and non-constants. > Also, are those global variable spaces kept contiguous regardless of optimizations? Yes, probably, mostly. Depending on the underlying object model. Generally the underying system will have at least three sections/segments in the underyling object model -- read only executable code, read only non-executable data, writable non-executable data. Sometimes the read only data will be merged with the code. The readonly data and writable data will not necessarily be contiguous, and/or there could be a small gap between them. It really depends on the underlying system. But why does it matter? - Jay From: dragisha at m3w.org Date: Sun, 21 Apr 2013 17:29:17 +0200 To: m3devel at elegosoft.com Subject: [M3devel] backend issues wrt garbage collection LLVM has a notion of a stacklet. So, stack is - possibly - non contiguous and as such it is not compatible with current GC. Fixable, but still an issue. Also, with C/C++ being a planned/developed backend, two issues emerge. One is - are global variables per module kept in contiguous space per module? Another is - what is compiler/backend/ABI/whatever of this final C/C++ compiler step and what it's stack is like? :) Also, are those global variable spaces kept contiguous regardless of optimizations? --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Apr 21 23:49:03 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Apr 2013 23:49:03 +0200 Subject: [M3devel] null type? In-Reply-To: References: Message-ID: <20130421234903.fbc4837a0cba1f1c28ebc2d7@elegosoft.com> On Sun, 21 Apr 2013 20:55:43 +0000 Jay K wrote: > What is the meaning of this: > > cm3/elego/graphicutils/src/RsrcFilter > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > (* Initializes the resource search path. *) > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > What are the types of p1, p2, etc.? Looks like REFANY; I think resources can actually be Bundle.Ts or TEXTs. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Apr 22 00:45:05 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 22 Apr 2013 00:45:05 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> Message-ID: https://github.com/dragisha/cm3 Please check if it is ok, whoever has time/will. Please keep in mind this is preliminary. -- Dragi?a Duri? dragisha at m3w.org On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: > I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. > > Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. > > First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. > > Report tomorrow, or so :) > -- > Dragi?a Duri? > dragisha at m3w.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rodney_bates at lcwb.coop Mon Apr 22 04:03:02 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Apr 2013 21:03:02 -0500 Subject: [M3devel] null type? In-Reply-To: References: Message-ID: <51749A56.4070909@lcwb.coop> On 04/21/2013 03:55 PM, Jay K wrote: > What is the meaning of this: > > cm3/elego/graphicutils/src/RsrcFilter > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > (* Initializes the resource search path. *) > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > Modula-3 says: 2.2.7: 'The following reference types are predeclared: ... NULL Contains only NIL' And: 2.2.8: 'A formal parameter declaration has the form Mode Name: Type := Default ... If Type is omitted, it is taken to be the type of Default.' And: 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' So all the pi's have type NULL, and only NIL can be passed to them as actuals. That's what the language says. It looks like the code in Init thinks it can get non-NIL reference values, but an attempt to pass one in a call should fail a runtime assignability check, since it won't be a member of NULL. When Init passes one of these to Convert (Yes, I peeked into RsrcFilter.m3), it is assignable, with no runtime check. Convert thinks it has a REFANY, and other calls to Convert could indeed give it something non-NIL, but not from the calls in Init. Of course, unsafe code could probably LOOPHOLE (remember, any word can be verbed) something non-NIL to NULL and pass it to init/Init. If the compiler did the most obvious thing, this might do what was apparently intended. But then again, a compiler would be fully compliant with the language and perfectly within its rights to optimize out such a parameter, not actually pass it at runtime at all, and just insert constant NIL wherever the formal was referenced in the body of Init, thus undermining the above intent. Which makes for a good example of how unsafe code (almost?) always depends on assumptions about what a compiler will do. > > What are the types of p1, p2, etc.? > > > - Jay From hosking at cs.purdue.edu Mon Apr 22 05:20:52 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Apr 2013 15:20:52 +1200 Subject: [M3devel] "fork" In-Reply-To: References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> Message-ID: <9E39D415-6986-4C16-A701-D75D76AA40B9@cs.purdue.edu> What happens to all the commit logs? I'd hate to lose those. They carry useful information. Sent from my iPhone On 21/04/2013, at 5:54 PM, Peter McKinna wrote: > Hi, > > I too support a clean move to git Great tool-set, very fast. > > The swig guys recently did a similar move to git, hosting it on github and all went very smoothly. > > Regards > > Peter > > > On Sun, Apr 21, 2013 at 3:33 PM, Dragi?a Duri? wrote: >> Well, this changes situation :). If nobody insists on CVS, then single jump from CVS to GIT is all we need. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: >> >>> In contrast to what I said two or three years ago, I now think that >>> a migration away from CVS is overdue, but I haven't had the time to do it >>> right and probably won't have that time in the near future. We _do_ have >>> several svn and git experts in our company, but I haven't been able >>> to inspire them to do the migration yet. >>> >>> Actually I think that the migration itself will be not very difficult; it is >>> the Hudson/Jenkins/Apache/scripts support that will mostly need to be >>> rewritten wrt. version control. I doubt that anybody outside of Elego has >>> done much work on that. >>> >>> I'd like to try to acquire some internal ressources again; so I'd ask >>> you to wait for some weeks. If I haven't been able to organize something >>> until June, I'd think it will be best if someone else takes over completely. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Apr 22 07:49:27 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 22 Apr 2013 07:49:27 +0200 Subject: [M3devel] "fork" In-Reply-To: <9E39D415-6986-4C16-A701-D75D76AA40B9@cs.purdue.edu> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> <9E39D415-6986-4C16-A701-D75D76AA40B9@cs.purdue.edu> Message-ID: <0F4CAC04-4699-4134-A246-4A6E07C2966A@m3w.org> Absolutely preserved. That's a reason why our choices are svn and git - there are great migration tools. -- Dragi?a Duri? dragisha at m3w.org On Apr 22, 2013, at 5:20 AM, Tony Hosking wrote: > What happens to all the commit logs? I'd hate to lose those. They carry useful information. > > Sent from my iPhone > > On 21/04/2013, at 5:54 PM, Peter McKinna wrote: > >> Hi, >> >> I too support a clean move to git Great tool-set, very fast. >> >> The swig guys recently did a similar move to git, hosting it on github and all went very smoothly. >> >> Regards >> >> Peter >> >> >> On Sun, Apr 21, 2013 at 3:33 PM, Dragi?a Duri? wrote: >> Well, this changes situation :). If nobody insists on CVS, then single jump from CVS to GIT is all we need. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: >> >>> In contrast to what I said two or three years ago, I now think that >>> a migration away from CVS is overdue, but I haven't had the time to do it >>> right and probably won't have that time in the near future. We _do_ have >>> several svn and git experts in our company, but I haven't been able >>> to inspire them to do the migration yet. >>> >>> Actually I think that the migration itself will be not very difficult; it is >>> the Hudson/Jenkins/Apache/scripts support that will mostly need to be >>> rewritten wrt. version control. I doubt that anybody outside of Elego has >>> done much work on that. >>> >>> I'd like to try to acquire some internal ressources again; so I'd ask >>> you to wait for some weeks. If I haven't been able to organize something >>> until June, I'd think it will be best if someone else takes over completely. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Apr 22 08:46:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 22 Apr 2013 08:46:22 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> Message-ID: <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> http://pastebin.com/pWvsYqdj Tags converted, in final phase. All comments, changesets? Came before, during conversion process on my computer. -- Dragi?a Duri? dragisha at m3w.org On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: > https://github.com/dragisha/cm3 > > Please check if it is ok, whoever has time/will. > > Please keep in mind this is preliminary. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: > >> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >> >> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >> >> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >> >> Report tomorrow, or so :) >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Mon Apr 22 19:38:28 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Apr 2013 17:38:28 +0000 Subject: [M3devel] null type? In-Reply-To: <51749A56.4070909@lcwb.coop> References: , <51749A56.4070909@lcwb.coop> Message-ID: Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it.This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. - Jay > Date: Sun, 21 Apr 2013 21:03:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] null type? > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > What is the meaning of this: > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > (* Initializes the resource search path. *) > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > Modula-3 says: > > 2.2.7: 'The following reference types are predeclared: > ... > NULL Contains only NIL' > > And: > > 2.2.8: 'A formal parameter declaration has the form > Mode Name: Type := Default > ... > If Type is omitted, it is taken to be the type of Default.' > > And: > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > So all the pi's have type NULL, and only NIL can be passed to them > as actuals. That's what the language says. It looks like the code > in Init thinks it can get non-NIL reference values, but an attempt to pass > one in a call should fail a runtime assignability check, since it > won't be a member of NULL. > > When Init passes one of these to Convert (Yes, I peeked into > RsrcFilter.m3), it is assignable, with no runtime check. Convert > thinks it has a REFANY, and other calls to Convert could indeed > give it something non-NIL, but not from the calls in Init. > > Of course, unsafe code could probably LOOPHOLE (remember, any word > can be verbed) something non-NIL to NULL and pass it to init/Init. > If the compiler did the most obvious thing, this might do what was > apparently intended. > > But then again, a compiler would be fully compliant with the language > and perfectly within its rights to optimize out such a parameter, > not actually pass it at runtime at all, and just insert constant NIL > wherever the formal was referenced in the body of Init, thus undermining > the above intent. > > Which makes for a good example of how unsafe code (almost?) always > depends on assumptions about what a compiler will do. > > > > > What are the types of p1, p2, etc.? > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Apr 22 19:59:30 2013 From: darko at darko.org (Darko) Date: Mon, 22 Apr 2013 10:59:30 -0700 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop> Message-ID: A type denotes a set of allowable values. The NULL type is the set of values that only contains the value NIL. You need it because every expression has a static type so you need one for the expression "NIL". This to me looks like a bug. I have something similar in my code, declared CONST Nil: REFANY = Nil; so I can write PROCEDURE(a, b, c := Nil). Maybe that's what they had in mind but thinking the type of NIL was REFANY. On Apr 22, 2013, at 10:38 AM, Jay K wrote: > Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. > This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. > > > - Jay > > > Date: Sun, 21 Apr 2013 21:03:02 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] null type? > > > > > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > > What is the meaning of this: > > > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > > (* Initializes the resource search path. *) > > > > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > > > > Modula-3 says: > > > > 2.2.7: 'The following reference types are predeclared: > > ... > > NULL Contains only NIL' > > > > And: > > > > 2.2.8: 'A formal parameter declaration has the form > > Mode Name: Type := Default > > ... > > If Type is omitted, it is taken to be the type of Default.' > > > > And: > > > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > > > So all the pi's have type NULL, and only NIL can be passed to them > > as actuals. That's what the language says. It looks like the code > > in Init thinks it can get non-NIL reference values, but an attempt to pass > > one in a call should fail a runtime assignability check, since it > > won't be a member of NULL. > > > > When Init passes one of these to Convert (Yes, I peeked into > > RsrcFilter.m3), it is assignable, with no runtime check. Convert > > thinks it has a REFANY, and other calls to Convert could indeed > > give it something non-NIL, but not from the calls in Init. > > > > Of course, unsafe code could probably LOOPHOLE (remember, any word > > can be verbed) something non-NIL to NULL and pass it to init/Init. > > If the compiler did the most obvious thing, this might do what was > > apparently intended. > > > > But then again, a compiler would be fully compliant with the language > > and perfectly within its rights to optimize out such a parameter, > > not actually pass it at runtime at all, and just insert constant NIL > > wherever the formal was referenced in the body of Init, thus undermining > > the above intent. > > > > Which makes for a good example of how unsafe code (almost?) always > > depends on assumptions about what a compiler will do. > > > > > > > > What are the types of p1, p2, etc.? > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Apr 22 20:13:16 2013 From: darko at darko.org (Darko) Date: Mon, 22 Apr 2013 11:13:16 -0700 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop> Message-ID: That should read CONST Nil: REFANY = NIL; and no, you can't treat it like ADDRESS, it's equivalent to the enumeration TYPE NULL = {NIL}; On Apr 22, 2013, at 10:59 AM, Darko wrote: > A type denotes a set of allowable values. The NULL type is the set of values that only contains the value NIL. You need it because every expression has a static type so you need one for the expression "NIL". > > This to me looks like a bug. I have something similar in my code, declared CONST Nil: REFANY = Nil; so I can write PROCEDURE(a, b, c := Nil). Maybe that's what they had in mind but thinking the type of NIL was REFANY. > > > On Apr 22, 2013, at 10:38 AM, Jay K wrote: > >> Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. >> This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. >> >> >> - Jay >> >> > Date: Sun, 21 Apr 2013 21:03:02 -0500 >> > From: rodney_bates at lcwb.coop >> > To: m3devel at elegosoft.com >> > Subject: Re: [M3devel] null type? >> > >> > >> > >> > On 04/21/2013 03:55 PM, Jay K wrote: >> > > What is the meaning of this: >> > > >> > > cm3/elego/graphicutils/src/RsrcFilter >> > > >> > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; >> > > (* Initializes the resource search path. *) >> > > >> > > >> > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = >> > > >> > >> > Modula-3 says: >> > >> > 2.2.7: 'The following reference types are predeclared: >> > ... >> > NULL Contains only NIL' >> > >> > And: >> > >> > 2.2.8: 'A formal parameter declaration has the form >> > Mode Name: Type := Default >> > ... >> > If Type is omitted, it is taken to be the type of Default.' >> > >> > And: >> > >> > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' >> > >> > So all the pi's have type NULL, and only NIL can be passed to them >> > as actuals. That's what the language says. It looks like the code >> > in Init thinks it can get non-NIL reference values, but an attempt to pass >> > one in a call should fail a runtime assignability check, since it >> > won't be a member of NULL. >> > >> > When Init passes one of these to Convert (Yes, I peeked into >> > RsrcFilter.m3), it is assignable, with no runtime check. Convert >> > thinks it has a REFANY, and other calls to Convert could indeed >> > give it something non-NIL, but not from the calls in Init. >> > >> > Of course, unsafe code could probably LOOPHOLE (remember, any word >> > can be verbed) something non-NIL to NULL and pass it to init/Init. >> > If the compiler did the most obvious thing, this might do what was >> > apparently intended. >> > >> > But then again, a compiler would be fully compliant with the language >> > and perfectly within its rights to optimize out such a parameter, >> > not actually pass it at runtime at all, and just insert constant NIL >> > wherever the formal was referenced in the body of Init, thus undermining >> > the above intent. >> > >> > Which makes for a good example of how unsafe code (almost?) always >> > depends on assumptions about what a compiler will do. >> > >> > > >> > > What are the types of p1, p2, etc.? >> > > >> > > >> > > - Jay >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Tue Apr 23 01:29:06 2013 From: lists at darko.org (Darko Volaric) Date: Mon, 22 Apr 2013 16:29:06 -0700 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> Message-ID: There's another aspect of the NULL type which should be considered here. NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor of all reference types, NULL is the ultimate descendant of all reference types. As a result any variable of a reference type can be assigned NIL. Because of its unusual position, NIL is the only member of type NULL, since no other value makes sense (which is why it's sometimes called the "absurd" type). On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: > Disclosure: I knew they are of type "NULL", but I didn't/don't know what > that type is, or have a mental model for it. > This about the only place in the entire tree that uses this type. It > triggers an error in the C backend, but should be trivial to fix. I can > just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the > frontend's job. The error is just that I check that I know about every > type. Some types are "predeclared", some come from the frontend. I'll > predeclare this. Arguably nothing should be predeclared. > > > - Jay > > > Date: Sun, 21 Apr 2013 21:03:02 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] null type? > > > > > > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > > What is the meaning of this: > > > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > > (* Initializes the resource search path. *) > > > > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > > > > Modula-3 says: > > > > 2.2.7: 'The following reference types are predeclared: > > ... > > NULL Contains only NIL' > > > > And: > > > > 2.2.8: 'A formal parameter declaration has the form > > Mode Name: Type := Default > > ... > > If Type is omitted, it is taken to be the type of Default.' > > > > And: > > > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > > > So all the pi's have type NULL, and only NIL can be passed to them > > as actuals. That's what the language says. It looks like the code > > in Init thinks it can get non-NIL reference values, but an attempt to > pass > > one in a call should fail a runtime assignability check, since it > > won't be a member of NULL. > > > > When Init passes one of these to Convert (Yes, I peeked into > > RsrcFilter.m3), it is assignable, with no runtime check. Convert > > thinks it has a REFANY, and other calls to Convert could indeed > > give it something non-NIL, but not from the calls in Init. > > > > Of course, unsafe code could probably LOOPHOLE (remember, any word > > can be verbed) something non-NIL to NULL and pass it to init/Init. > > If the compiler did the most obvious thing, this might do what was > > apparently intended. > > > > But then again, a compiler would be fully compliant with the language > > and perfectly within its rights to optimize out such a parameter, > > not actually pass it at runtime at all, and just insert constant NIL > > wherever the formal was referenced in the body of Init, thus undermining > > the above intent. > > > > Which makes for a good example of how unsafe code (almost?) always > > depends on assumptions about what a compiler will do. > > > > > > > > What are the types of p1, p2, etc.? > > > > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 23 06:49:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Apr 2013 04:49:25 +0000 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop>, , Message-ID: > That should read CONST Nil: REFANY = NIL; and no, you can't > treat it like ADDRESS, it's equivalent to the enumeration TYPE NULL = {NIL}; At the backend level? It is always CGType.Addr, right? And there are not fields within a struct being pointed to, right? Our backend interface has two type systems. 1) CGType = roughly [int8, uint8, int16, uint16, int32, uint32, int64, uint64, float, double, extended, addr, struct] That is it -- pointers are just addresses, no type beyond that. Be they record pointers or objects or VAR parameters. Structs have a size associated with them as needed. But no fields. 2) typeids, opaques, structs, enums, typenames, objects, fields, methods They are overlapping. The NTx86 backend does nothing with the second set of types, and it works, and it is correct. Debugging is not good. The gcc backend, only for some targets, encodes the second set of types in strange ways that only m3gdb understands. They have no affect on codegen, and some targets, e.g. Darwin and I think HP-UX, ignore them entirely. Debugging is not good on Darwin or with stock debuggers. In the C backend, originally, I also ignored the second set. And again, it works but debugging was poor.Now in the C backend, I pay a lot of attention to the second set and it is much better. Not quite done, but getting there. The question is in that context. Given a variable/parameter of type NULL, what is its best most typeful representation in C or C++?Probably just void* or char*. - Jay Date: Mon, 22 Apr 2013 16:29:06 -0700 From: lists at darko.org To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] null type? There's another aspect of the NULL type which should be considered here. NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor of all reference types, NULL is the ultimate descendant of all reference types. As a result any variable of a reference type can be assigned NIL. Because of its unusual position, NIL is the only member of type NULL, since no other value makes sense (which is why it's sometimes called the "absurd" type). On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. - Jay > Date: Sun, 21 Apr 2013 21:03:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] null type? > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > What is the meaning of this: > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > (* Initializes the resource search path. *) > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > Modula-3 says: > > 2.2.7: 'The following reference types are predeclared: > ... > NULL Contains only NIL' > > And: > > 2.2.8: 'A formal parameter declaration has the form > Mode Name: Type := Default > ... > If Type is omitted, it is taken to be the type of Default.' > > And: > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > So all the pi's have type NULL, and only NIL can be passed to them > as actuals. That's what the language says. It looks like the code > in Init thinks it can get non-NIL reference values, but an attempt to pass > one in a call should fail a runtime assignability check, since it > won't be a member of NULL. > > When Init passes one of these to Convert (Yes, I peeked into > RsrcFilter.m3), it is assignable, with no runtime check. Convert > thinks it has a REFANY, and other calls to Convert could indeed > give it something non-NIL, but not from the calls in Init. > > Of course, unsafe code could probably LOOPHOLE (remember, any word > can be verbed) something non-NIL to NULL and pass it to init/Init. > If the compiler did the most obvious thing, this might do what was > apparently intended. > > But then again, a compiler would be fully compliant with the language > and perfectly within its rights to optimize out such a parameter, > not actually pass it at runtime at all, and just insert constant NIL > wherever the formal was referenced in the body of Init, thus undermining > the above intent. > > Which makes for a good example of how unsafe code (almost?) always > depends on assumptions about what a compiler will do. > > > > > What are the types of p1, p2, etc.? > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 23 07:24:11 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 23 Apr 2013 07:24:11 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> Message-ID: Anybody had a look at final conversion? Jay? -- Dragi?a Duri? dragisha at m3w.org On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: > http://pastebin.com/pWvsYqdj > > Tags converted, in final phase. All comments, changesets? Came before, during conversion process on my computer. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: > >> https://github.com/dragisha/cm3 >> >> Please check if it is ok, whoever has time/will. >> >> Please keep in mind this is preliminary. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >> >>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>> >>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>> >>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>> >>> Report tomorrow, or so :) >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Tue Apr 23 23:37:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Apr 2013 21:37:33 +0000 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, Message-ID: I have pretty much never used git or svn. I learn new source control systems kinda slowly.I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. Thank you, - Jay From: dragisha at m3w.org Date: Tue, 23 Apr 2013 07:24:11 +0200 To: m3devel at elegosoft.com Subject: Re: [M3devel] Trial conversion(s) Anybody had a look at final conversion? Jay? --Dragi?a Duri?dragisha at m3w.org On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote:http://pastebin.com/pWvsYqdj Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. --Dragi?a Duri?dragisha at m3w.org On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote:https://github.com/dragisha/cm3 Please check if it is ok, whoever has time/will. Please keep in mind this is preliminary. --Dragi?a Duri?dragisha at m3w.org On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote:I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. Report tomorrow, or so :) --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 24 02:14:36 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 23 Apr 2013 17:14:36 -0700 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> Message-ID: <20130424001436.F01F01A207D@async.async.caltech.edu> I'm pretty sure the original code is buggy. The best type to represent NULL in C(++) I think would be no type at all, that is, strip the parameter and replace it with a constant (void *)0. Of course you might have some mismatches if you do that. Second closest would be some singleton type. But I would add that there has been a Modula-3 compiler that treats a declaration of a := NIL as a : REFANY := NIL but that was a buggy compiler. I had made the mistake in my own code a few times and when I upgraded my compiler once, it stopped working (as it should have). Mika Darko Volaric writes: >--047d7bd76f785e671604dafb6f57 >Content-Type: text/plain; charset=ISO-8859-1 > >There's another aspect of the NULL type which should be considered here. >NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor >of all reference types, NULL is the ultimate descendant of >all reference types. As a result any variable of a reference type can be >assigned NIL. Because of its unusual position, NIL is the only member of >type NULL, since no other value makes sense (which is why it's sometimes >called the "absurd" type). > > >On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: > >> Disclosure: I knew they are of type "NULL", but I didn't/don't know what >> that type is, or have a mental model for it. >> This about the only place in the entire tree that uses this type. It >> triggers an error in the C backend, but should be trivial to fix. I can >> just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the >> frontend's job. The error is just that I check that I know about every >> type. Some types are "predeclared", some come from the frontend. I'll >> predeclare this. Arguably nothing should be predeclared. >> >> >> - Jay >> >> > Date: Sun, 21 Apr 2013 21:03:02 -0500 >> > From: rodney_bates at lcwb.coop >> > To: m3devel at elegosoft.com >> > Subject: Re: [M3devel] null type? >> >> > >> > >> > >> > On 04/21/2013 03:55 PM, Jay K wrote: >> > > What is the meaning of this: >> > > >> > > cm3/elego/graphicutils/src/RsrcFilter >> > > >> > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; >> > > (* Initializes the resource search path. *) >> > > >> > > >> > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = >> > > >> > >> > Modula-3 says: >> > >> > 2.2.7: 'The following reference types are predeclared: >> > ... >> > NULL Contains only NIL' >> > >> > And: >> > >> > 2.2.8: 'A formal parameter declaration has the form >> > Mode Name: Type := Default >> > ... >> > If Type is omitted, it is taken to be the type of Default.' >> > >> > And: >> > >> > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' >> > >> > So all the pi's have type NULL, and only NIL can be passed to them >> > as actuals. That's what the language says. It looks like the code >> > in Init thinks it can get non-NIL reference values, but an attempt to >> pass >> > one in a call should fail a runtime assignability check, since it >> > won't be a member of NULL. >> > >> > When Init passes one of these to Convert (Yes, I peeked into >> > RsrcFilter.m3), it is assignable, with no runtime check. Convert >> > thinks it has a REFANY, and other calls to Convert could indeed >> > give it something non-NIL, but not from the calls in Init. >> > >> > Of course, unsafe code could probably LOOPHOLE (remember, any word >> > can be verbed) something non-NIL to NULL and pass it to init/Init. >> > If the compiler did the most obvious thing, this might do what was >> > apparently intended. >> > >> > But then again, a compiler would be fully compliant with the language >> > and perfectly within its rights to optimize out such a parameter, >> > not actually pass it at runtime at all, and just insert constant NIL >> > wherever the formal was referenced in the body of Init, thus undermining >> > the above intent. >> > >> > Which makes for a good example of how unsafe code (almost?) always >> > depends on assumptions about what a compiler will do. >> > >> > > >> > > What are the types of p1, p2, etc.? >> > > >> > > >> > > - Jay >> > >> > >--047d7bd76f785e671604dafb6f57 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > >
There's another aspect of the NULL type which should b= >e considered here. NULL is the complement of REFANY. Just as REFANY is the = >ultimate ancestor of all reference types, NULL is the ultimate=A0descendant= > of all=A0reference=A0types. As a result any variable of a reference type c= >an be assigned NIL.=A0Because=A0of its unusual position, NIL is the only me= >mber of type NULL, since no other value makes sense (which is why it's = >sometimes called the "absurd" type).
>


On Mon, Apr 2= >2, 2013 at 10:38 AM, Jay K <l at cornell.edu" target=3D"_blank">jay.krell at cornell.edu> wrote= >:
ft:1px #ccc solid;padding-left:1ex"> > > > >
Disclosure: I knew they are of type "NULL",= > but I didn't/don't know what that type is, or have a mental model = >for it.
This about the only place in the entire tree that uses this type= >. It triggers an error in the C backend, but should be trivial to fix. I ca= >n just treat this as=A0"ADDRESS" presumably. Checks that it is NI= >L, that is the frontend's job. The error is just that I check that I kn= >ow about every type. Some types are "predeclared", some come from= > the frontend. I'll predeclare this. Arguably nothing should be predecl= >ared.
>=A0
=A0
=A0=A0- Jay
=A0
> Date: Sun, 21 Apr = >2013 21:03:02 -0500
> From: target=3D"_blank">rodney_bates at lcwb.coop
> To: :m3devel at elegosoft.com" target=3D"_blank">m3devel at elegosoft.com
>> Subject: Re: [M3devel] null type?

>
&= >gt;
>
> On 04/21/2013 03:55 PM, Jay K wrote:
> > Wha= >t is the meaning of this:
> >
> > cm3/elego/graphicutils/= >src/RsrcFilter
>> >
> > init(p1, p2, p3, p4, p5, p6 :=3D NIL) : T;
&= >gt; > (* Initializes the resource search path. *)
> >
&= >gt; >
> > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 :=3D = >NIL) : T =3D
>> >
>
> Modula-3 says:
>
> 2.2.7: 'The = >following reference types are predeclared:
> ...
> = > NULL Contains only NIL'
>
> And:
>
> = >2.2.8: 'A formal parameter declaration has the form
>> Mode Name: Type :=3D Default
> ...
> = > If Type is omitted, it is taken to be the type of Default.'
= >>
> And:
>
> 2.6.6: 'The literal "NIL"= > denotes the value NIL. Its type is NULL.'
>>
> So all the pi's have type NULL, and only NIL can be passe= >d to them
> as actuals. That's what the language says. It look= >s like the code
> in Init thinks it can get non-NIL reference values,= > but an attempt to pass
>> one in a call should fail a runtime assignability check, since it
&= >gt; won't be a member of NULL.
>
> When Init passes one of= > these to Convert (Yes, I peeked into
> RsrcFilter.m3), it is assigna= >ble, with no runtime check. Convert
>> thinks it has a REFANY, and other calls to Convert could indeed
>= >; give it something non-NIL, but not from the calls in Init.
>
&g= >t; Of course, unsafe code could probably LOOPHOLE (remember, any word
>> can be verbed) something non-NIL to NULL and pass it to init/Init.
= >> If the compiler did the most obvious thing, this might do what was
= >> apparently intended.
>
> But then again, a compiler would= > be fully compliant with the language
>> and perfectly within its rights to optimize out such a parameter,
&= >gt; not actually pass it at runtime at all, and just insert constant NIL>> wherever the formal was referenced in the body of Init, thus undermin= >ing
>> the above intent.
>
> Which makes for a good example of h= >ow unsafe code (almost?) always
> depends on assumptions about what a= > compiler will do.
>
> >
> > What are the types of= > p1, p2, etc.?
>> >
> >
> > - Jay
>
= >
>

> >--047d7bd76f785e671604dafb6f57-- From hendrik at topoi.pooq.com Wed Apr 24 05:09:39 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 23 Apr 2013 23:09:39 -0400 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> Message-ID: <20130424030938.GA32407@topoi.pooq.com> On Mon, Apr 22, 2013 at 04:29:06PM -0700, Darko Volaric wrote: > There's another aspect of the NULL type which should be considered here. > NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor > of all reference types, NULL is the ultimate descendant of > all reference types. As a result any variable of a reference type can be > assigned NIL. Because of its unusual position, NIL is the only member of > type NULL, since no other value makes sense (which is why it's sometimes > called the "absurd" type). I think that terminology comes from the type lattice, and perhaps also from the propositions as types formalism. The type that is properly "absurd" is the type with no elements at all, corresponding to the empty set. A functino returning a value of this type can never return, because there are no values of that type. But since Modula 3 (as many other languages) has no truly empty type, the bottom of the type lattice is NULL, and I suppose its kind of plausible that it get called "absurd" for that reason. -- hendrik From dragisha at m3w.org Wed Apr 24 07:55:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 24 Apr 2013 07:55:15 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, Message-ID: <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ I've used githowto.com some time ago. Looks great. It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. dd -- Dragi?a Duri? dragisha at m3w.org On Apr 23, 2013, at 11:37 PM, Jay K wrote: > I have pretty much never used git or svn. I learn new source control systems kinda slowly. > I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. > > Thank you, > - Jay > > From: dragisha at m3w.org > Date: Tue, 23 Apr 2013 07:24:11 +0200 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Trial conversion(s) > > Anybody had a look at final conversion? Jay? > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: > > http://pastebin.com/pWvsYqdj > > Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: > > https://github.com/dragisha/cm3 > > Please check if it is ok, whoever has time/will. > > Please keep in mind this is preliminary. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: > > I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. > > Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. > > First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. > > Report tomorrow, or so :) > -- > Dragi?a Duri? > dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 24 08:50:33 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 24 Apr 2013 08:50:33 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> Message-ID: I only checked Windows tools now, and found this: http://windows.github.com/ There is also github for Mac. On Unix/Linux it is native. For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). dd On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: > I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ > > I've used githowto.com some time ago. Looks great. > > It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. > > dd > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 23, 2013, at 11:37 PM, Jay K wrote: > >> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >> >> Thank you, >> - Jay >> >> From: dragisha at m3w.org >> Date: Tue, 23 Apr 2013 07:24:11 +0200 >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Trial conversion(s) >> >> Anybody had a look at final conversion? Jay? >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >> >> http://pastebin.com/pWvsYqdj >> >> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >> >> https://github.com/dragisha/cm3 >> >> Please check if it is ok, whoever has time/will. >> >> Please keep in mind this is preliminary. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >> >> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >> >> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >> >> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >> >> Report tomorrow, or so :) >> -- >> Dragi?a Duri? >> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 24 14:16:29 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 24 Apr 2013 14:16:29 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> Message-ID: <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> I don't know, really. Have you tried? -- Dragi?a Duri? dragisha at m3w.org On Apr 24, 2013, at 1:52 PM, Darko wrote: > Is there no way for us to sign up as collaborators ourselves and be approved? > > > On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: > >> I only checked Windows tools now, and found this: http://windows.github.com/ >> >> There is also github for Mac. >> >> On Unix/Linux it is native. >> >> For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). >> >> dd >> >> On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: >> >>> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >>> >>> I've used githowto.com some time ago. Looks great. >>> >>> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >>> >>> dd >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >>> >>>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>>> >>>> Thank you, >>>> - Jay >>>> >>>> From: dragisha at m3w.org >>>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Trial conversion(s) >>>> >>>> Anybody had a look at final conversion? Jay? >>>> >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>>> >>>> http://pastebin.com/pWvsYqdj >>>> >>>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>>> >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>>> >>>> https://github.com/dragisha/cm3 >>>> >>>> Please check if it is ok, whoever has time/will. >>>> >>>> Please keep in mind this is preliminary. >>>> >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>>> >>>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>>> >>>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>>> >>>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>>> >>>> Report tomorrow, or so :) >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 13:52:55 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 04:52:55 -0700 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> Message-ID: Is there no way for us to sign up as collaborators ourselves and be approved? On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: > I only checked Windows tools now, and found this: http://windows.github.com/ > > There is also github for Mac. > > On Unix/Linux it is native. > > For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). > > dd > > On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: > >> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >> >> I've used githowto.com some time ago. Looks great. >> >> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >> >> dd >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >> >>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>> >>> Thank you, >>> - Jay >>> >>> From: dragisha at m3w.org >>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Trial conversion(s) >>> >>> Anybody had a look at final conversion? Jay? >>> >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>> >>> http://pastebin.com/pWvsYqdj >>> >>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>> >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>> >>> https://github.com/dragisha/cm3 >>> >>> Please check if it is ok, whoever has time/will. >>> >>> Please keep in mind this is preliminary. >>> >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>> >>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>> >>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>> >>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>> >>> Report tomorrow, or so :) >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 15:40:23 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 06:40:23 -0700 Subject: [M3devel] Trial conversion(s) In-Reply-To: <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> Message-ID: There doesn't seem to be an option to add yourself as a collaborator to that repository. Can we open a "cm3" organization account for the final repository? On Apr 24, 2013, at 5:16 AM, Dragi?a Duri? wrote: > I don't know, really. Have you tried? > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 24, 2013, at 1:52 PM, Darko wrote: > >> Is there no way for us to sign up as collaborators ourselves and be approved? >> >> >> On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: >> >>> I only checked Windows tools now, and found this: http://windows.github.com/ >>> >>> There is also github for Mac. >>> >>> On Unix/Linux it is native. >>> >>> For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). >>> >>> dd >>> >>> On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: >>> >>>> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >>>> >>>> I've used githowto.com some time ago. Looks great. >>>> >>>> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >>>> >>>> dd >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >>>> >>>>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>>>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>>>> >>>>> Thank you, >>>>> - Jay >>>>> >>>>> From: dragisha at m3w.org >>>>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Trial conversion(s) >>>>> >>>>> Anybody had a look at final conversion? Jay? >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>>>> >>>>> http://pastebin.com/pWvsYqdj >>>>> >>>>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>>>> >>>>> https://github.com/dragisha/cm3 >>>>> >>>>> Please check if it is ok, whoever has time/will. >>>>> >>>>> Please keep in mind this is preliminary. >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>>>> >>>>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>>>> >>>>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>>>> >>>>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>>>> >>>>> Report tomorrow, or so :) >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 14:10:45 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 05:10:45 -0700 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop>, , Message-ID: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> I think the correct approach is to treat a variable declaration with a type NULL as an error. The correspondence to C would be void, but just void, not void*. What is the representation of the declaration "void x"? I'm guessing C doesn't allow that. On Apr 22, 2013, at 9:49 PM, Jay K wrote: > > That should read CONST Nil: REFANY = NIL; and no, you can't > > treat it like ADDRESS, it's equivalent to the enumeration TYPE NULL = {NIL}; > > At the backend level? > It is always CGType.Addr, right? > And there are not fields within a struct being pointed to, right? > > > Our backend interface has two type systems. > 1) CGType = roughly [int8, uint8, int16, uint16, int32, uint32, int64, uint64, float, double, extended, addr, struct] > That is it -- pointers are just addresses, no type beyond that. Be they record pointers or objects or VAR parameters. > Structs have a size associated with them as needed. But no fields. > 2) typeids, opaques, structs, enums, typenames, objects, fields, methods > > > They are overlapping. > The NTx86 backend does nothing with the second set of types, and it works, and it is correct. Debugging is not good. > The gcc backend, only for some targets, encodes the second set of types in strange ways that only m3gdb understands. They have no affect on codegen, and some targets, e.g. Darwin and I think HP-UX, ignore them entirely. Debugging is not good on Darwin or with stock debuggers. > > > In the C backend, originally, I also ignored the second set. And again, it works but debugging was poor. > Now in the C backend, I pay a lot of attention to the second set and it is much better. Not quite done, but getting there. > > > The question is in that context. > > > Given a variable/parameter of type NULL, what is its best most typeful representation in C or C++? > Probably just void* or char*. > > > - Jay > Date: Mon, 22 Apr 2013 16:29:06 -0700 > From: lists at darko.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] null type? > > There's another aspect of the NULL type which should be considered here. NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor of all reference types, NULL is the ultimate descendant of all reference types. As a result any variable of a reference type can be assigned NIL. Because of its unusual position, NIL is the only member of type NULL, since no other value makes sense (which is why it's sometimes called the "absurd" type). > > > On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: > Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. > This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. > > > - Jay > > > Date: Sun, 21 Apr 2013 21:03:02 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] null type? > > > > > > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > > What is the meaning of this: > > > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > > (* Initializes the resource search path. *) > > > > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > > > > Modula-3 says: > > > > 2.2.7: 'The following reference types are predeclared: > > ... > > NULL Contains only NIL' > > > > And: > > > > 2.2.8: 'A formal parameter declaration has the form > > Mode Name: Type := Default > > ... > > If Type is omitted, it is taken to be the type of Default.' > > > > And: > > > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > > > So all the pi's have type NULL, and only NIL can be passed to them > > as actuals. That's what the language says. It looks like the code > > in Init thinks it can get non-NIL reference values, but an attempt to pass > > one in a call should fail a runtime assignability check, since it > > won't be a member of NULL. > > > > When Init passes one of these to Convert (Yes, I peeked into > > RsrcFilter.m3), it is assignable, with no runtime check. Convert > > thinks it has a REFANY, and other calls to Convert could indeed > > give it something non-NIL, but not from the calls in Init. > > > > Of course, unsafe code could probably LOOPHOLE (remember, any word > > can be verbed) something non-NIL to NULL and pass it to init/Init. > > If the compiler did the most obvious thing, this might do what was > > apparently intended. > > > > But then again, a compiler would be fully compliant with the language > > and perfectly within its rights to optimize out such a parameter, > > not actually pass it at runtime at all, and just insert constant NIL > > wherever the formal was referenced in the body of Init, thus undermining > > the above intent. > > > > Which makes for a good example of how unsafe code (almost?) always > > depends on assumptions about what a compiler will do. > > > > > > > > What are the types of p1, p2, etc.? > > > > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 14:02:18 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 05:02:18 -0700 Subject: [M3devel] null type? In-Reply-To: <20130424030938.GA32407@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <20130424030938.GA32407@topoi.pooq.com> Message-ID: It does come from the idea of the type lattice, but I think it's an important abstraction when thinking about types in any language. In my mind the "absurdity" is the idea that there can be some type that is a subtype of all things. Of course there is nothing that can be that, but even nothing has to be represented as some thing. In other languages a value of this bottom type is called "failure", which I think makes it clearer. "Null" is often interpreted as "don't know or don't care", which leadings to people thinking about the bottom type instead as the top type, so we have people assuming the type of NIL is REFANY. On Apr 23, 2013, at 8:09 PM, Hendrik Boom wrote: > On Mon, Apr 22, 2013 at 04:29:06PM -0700, Darko Volaric wrote: >> There's another aspect of the NULL type which should be considered here. >> NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor >> of all reference types, NULL is the ultimate descendant of >> all reference types. As a result any variable of a reference type can be >> assigned NIL. Because of its unusual position, NIL is the only member of >> type NULL, since no other value makes sense (which is why it's sometimes >> called the "absurd" type). > > I think that terminology comes from the type lattice, and perhaps also > from the propositions as types formalism. The type that is properly > "absurd" is the type with no elements at all, corresponding to the empty > set. A functino returning a value of this type can never return, > because there are no values of that type. > > But since Modula 3 (as many other languages) has no truly empty type, > the bottom of the type lattice is NULL, and I suppose its kind of > plausible that it get called "absurd" for that reason. > > -- hendrik From rodney_bates at lcwb.coop Wed Apr 24 20:59:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Apr 2013 13:59:40 -0500 Subject: [M3devel] null type? In-Reply-To: <20130424030938.GA32407@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <20130424030938.GA32407@topoi.pooq.com> Message-ID: <51782B9C.9040701@lcwb.coop> The main intended use for NULL in Modula-3 is not to declare variables with it, but as an alternative label in a TYPECASE statement, for which it is extremely convenient. Otherwise, a NIL would always match the first alternative, which is often not what you want. Wrapping an IF v = NIL THEN ... ELSE TYPECASE v OF ... around it would work, but be more awkward to code. Even more so if v were an expression involving runtime computation that you really didn't want done twice, inviting yet another wrapping by a WITH construct. Somewhere in all the informal language description stuff, this is spelled out, but it might take a lot of time to find it. On 04/23/2013 10:09 PM, Hendrik Boom wrote: > On Mon, Apr 22, 2013 at 04:29:06PM -0700, Darko Volaric wrote: >> There's another aspect of the NULL type which should be considered here. >> NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor >> of all reference types, NULL is the ultimate descendant of >> all reference types. As a result any variable of a reference type can be >> assigned NIL. Because of its unusual position, NIL is the only member of >> type NULL, since no other value makes sense (which is why it's sometimes >> called the "absurd" type). > > I think that terminology comes from the type lattice, and perhaps also > from the propositions as types formalism. The type that is properly > "absurd" is the type with no elements at all, corresponding to the empty > set. A functino returning a value of this type can never return, > because there are no values of that type. > > But since Modula 3 (as many other languages) has no truly empty type, > the bottom of the type lattice is NULL, and I suppose its kind of > plausible that it get called "absurd" for that reason. > > -- hendrik > From mika at async.caltech.edu Thu Apr 25 04:53:13 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 24 Apr 2013 19:53:13 -0700 Subject: [M3devel] null type? In-Reply-To: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> Message-ID: <20130425025313.1BCD71A207D@async.async.caltech.edu> Darko writes: > >--Apple-Mail-2--196294281 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=us-ascii > >I think the correct approach is to treat a variable declaration with a = >type NULL as an error. The correspondence to C would be void, but just = >void, not void*. What is the representation of the declaration "void = >x"? I'm guessing C doesn't allow that. It's not an error since there is precisely one legal value for such a variable, namely, NIL. That value can be inferred from the type without inspecting the variable. If you make it illegal to declare variables of type NULL you may have to go back and change various code generators that depend on it. There are types that are truly empty in Modula-3, and it is illegal to declare variables of those types (but not illegal to declare those types or to use them to construct other types), e.g., CONST A = 3; B = 1; TYPE T = [A..B]; VAR t : T; (* static error *) TYPE A = ARRAY T OF X; (* not an error *) etc. From darko at darko.org Thu Apr 25 05:11:17 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 20:11:17 -0700 Subject: [M3devel] null type? In-Reply-To: <20130425025313.1BCD71A207D@async.async.caltech.edu> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> Message-ID: <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> Probably not a good idea to make it illegal for backwards compatibility if you really think it's going to break things, so perhaps issue a warning instead. But besides providing a type for NIL it doesn't serve much purpose and I can't see anything being lost by outlawing it, eliminating the confusion with REFANY might be gained. Just because it's a valid bit of code doesn't mean it's not a bug. Looking at the code you can reasonably assume the author thought NIL was of type REFANY. It's a useless declaration unless it's trying to make some sort of point by being useless. It's a declaration to pass in one possible value which it's already assigned and which you can't change. On Apr 24, 2013, at 7:53 PM, mika at async.caltech.edu wrote: > Darko writes: >> >> --Apple-Mail-2--196294281 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/plain; >> charset=us-ascii >> >> I think the correct approach is to treat a variable declaration with a = >> type NULL as an error. The correspondence to C would be void, but just = >> void, not void*. What is the representation of the declaration "void = >> x"? I'm guessing C doesn't allow that. > > It's not an error since there is precisely one legal value for such a variable, > namely, NIL. That value can be inferred from the type without inspecting the > variable. > > If you make it illegal to declare variables of type NULL you may have to go > back and change various code generators that depend on it. > > There are types that are truly empty in Modula-3, and it is illegal to > declare variables of those types (but not illegal to declare those types > or to use them to construct other types), e.g., > > CONST > A = 3; > B = 1; > > TYPE > T = [A..B]; > > VAR > t : T; (* static error *) > > TYPE > A = ARRAY T OF X; (* not an error *) > > etc. From mika at async.caltech.edu Thu Apr 25 05:45:32 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 24 Apr 2013 20:45:32 -0700 Subject: [M3devel] null type? In-Reply-To: <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> Message-ID: <20130425034532.F2CD01A207D@async.async.caltech.edu> What is lost is some of the mathematical simplicity of the type system. A type is just a set of values. There is nothing odd about a type that can contain a single value. By your logic, we should outlaw declarations of variables of type [1..1] as well. Or variables of type { OK } (one-value enumerations). The upshot would be to require special-case code in programs that *generate* Modula-3 code to check for types of a single value and avoid those through some gyrations involving value substitutions. I can see how that could be a big hassle in some cases---it would require the aforementioned code generators to be able to perform value substitutions and possibly dead-code elimination. Mika Darko writes: >Probably not a good idea to make it illegal for backwards compatibility = >if you really think it's going to break things, so perhaps issue a = >warning instead. But besides providing a type for NIL it doesn't serve = >much purpose and I can't see anything being lost by outlawing it, = >eliminating the confusion with REFANY might be gained. > >Just because it's a valid bit of code doesn't mean it's not a bug. = >Looking at the code you can reasonably assume the author thought NIL was = >of type REFANY. It's a useless declaration unless it's trying to make = >some sort of point by being useless. It's a declaration to pass in one = >possible value which it's already assigned and which you can't change.=20= > > > >On Apr 24, 2013, at 7:53 PM, mika at async.caltech.edu wrote: > >> Darko writes: >>>=20 >>> --Apple-Mail-2--196294281 >>> Content-Transfer-Encoding: quoted-printable >>> Content-Type: text/plain; >>> charset=3Dus-ascii >>>=20 >>> I think the correct approach is to treat a variable declaration with = >a =3D >>> type NULL as an error. The correspondence to C would be void, but = >just =3D >>> void, not void*. What is the representation of the declaration "void = >=3D >>> x"? I'm guessing C doesn't allow that. >>=20 >> It's not an error since there is precisely one legal value for such a = >variable, >> namely, NIL. That value can be inferred from the type without = >inspecting the >> variable. >>=20 >> If you make it illegal to declare variables of type NULL you may have = >to go >> back and change various code generators that depend on it. >>=20 >> There are types that are truly empty in Modula-3, and it is illegal to >> declare variables of those types (but not illegal to declare those = >types >> or to use them to construct other types), e.g., >>=20 >> CONST >> A =3D 3; >> B =3D 1; >>=20 >> TYPE >> T =3D [A..B]; >>=20 >> VAR >> t : T; (* static error *) >>=20 >> TYPE >> A =3D ARRAY T OF X; (* not an error *) >>=20 >> etc. From darko at darko.org Thu Apr 25 06:06:32 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 21:06:32 -0700 Subject: [M3devel] null type? In-Reply-To: <20130425034532.F2CD01A207D@async.async.caltech.edu> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> Message-ID: You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. On Apr 24, 2013, at 8:45 PM, mika at async.caltech.edu wrote: > What is lost is some of the mathematical simplicity of the type system. > > A type is just a set of values. > > There is nothing odd about a type that can contain a single value. > > By your logic, we should outlaw declarations of variables of type [1..1] > as well. Or variables of type { OK } (one-value enumerations). > > The upshot would be to require special-case code in programs that > *generate* Modula-3 code to check for types of a single value > and avoid those through some gyrations involving value substitutions. > > I can see how that could be a big hassle in some cases---it would require > the aforementioned code generators to be able to perform value substitutions > and possibly dead-code elimination. > > Mika > > > > > Darko writes: >> Probably not a good idea to make it illegal for backwards compatibility = >> if you really think it's going to break things, so perhaps issue a = >> warning instead. But besides providing a type for NIL it doesn't serve = >> much purpose and I can't see anything being lost by outlawing it, = >> eliminating the confusion with REFANY might be gained. >> >> Just because it's a valid bit of code doesn't mean it's not a bug. = >> Looking at the code you can reasonably assume the author thought NIL was = >> of type REFANY. It's a useless declaration unless it's trying to make = >> some sort of point by being useless. It's a declaration to pass in one = >> possible value which it's already assigned and which you can't change.=20= >> >> >> >> On Apr 24, 2013, at 7:53 PM, mika at async.caltech.edu wrote: >> >>> Darko writes: >>>> =20 >>>> --Apple-Mail-2--196294281 >>>> Content-Transfer-Encoding: quoted-printable >>>> Content-Type: text/plain; >>>> charset=3Dus-ascii >>>> =20 >>>> I think the correct approach is to treat a variable declaration with = >> a =3D >>>> type NULL as an error. The correspondence to C would be void, but = >> just =3D >>>> void, not void*. What is the representation of the declaration "void = >> =3D >>>> x"? I'm guessing C doesn't allow that. >>> =20 >>> It's not an error since there is precisely one legal value for such a = >> variable, >>> namely, NIL. That value can be inferred from the type without = >> inspecting the >>> variable. >>> =20 >>> If you make it illegal to declare variables of type NULL you may have = >> to go >>> back and change various code generators that depend on it. >>> =20 >>> There are types that are truly empty in Modula-3, and it is illegal to >>> declare variables of those types (but not illegal to declare those = >> types >>> or to use them to construct other types), e.g., >>> =20 >>> CONST >>> A =3D 3; >>> B =3D 1; >>> =20 >>> TYPE >>> T =3D [A..B]; >>> =20 >>> VAR >>> t : T; (* static error *) >>> =20 >>> TYPE >>> A =3D ARRAY T OF X; (* not an error *) >>> =20 >>> etc. From dragisha at m3w.org Thu Apr 25 07:38:46 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 25 Apr 2013 07:38:46 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> Message-ID: Great idea! https://github.com/blog/674-introducing-organizations cm3 organization is already created on github, and also modula-3 exists. Ideas? -- Dragi?a Duri? dragisha at m3w.org On Apr 24, 2013, at 3:40 PM, Darko wrote: > There doesn't seem to be an option to add yourself as a collaborator to that repository. Can we open a "cm3" organization account for the final repository? > > > On Apr 24, 2013, at 5:16 AM, Dragi?a Duri? wrote: > >> I don't know, really. Have you tried? >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 24, 2013, at 1:52 PM, Darko wrote: >> >>> Is there no way for us to sign up as collaborators ourselves and be approved? >>> >>> >>> On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: >>> >>>> I only checked Windows tools now, and found this: http://windows.github.com/ >>>> >>>> There is also github for Mac. >>>> >>>> On Unix/Linux it is native. >>>> >>>> For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). >>>> >>>> dd >>>> >>>> On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: >>>> >>>>> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >>>>> >>>>> I've used githowto.com some time ago. Looks great. >>>>> >>>>> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >>>>> >>>>> dd >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >>>>> >>>>>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>>>>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>>>>> >>>>>> Thank you, >>>>>> - Jay >>>>>> >>>>>> From: dragisha at m3w.org >>>>>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Trial conversion(s) >>>>>> >>>>>> Anybody had a look at final conversion? Jay? >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>>> >>>>>> >>>>>> >>>>>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>>>>> >>>>>> http://pastebin.com/pWvsYqdj >>>>>> >>>>>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>>> >>>>>> >>>>>> >>>>>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>>>>> >>>>>> https://github.com/dragisha/cm3 >>>>>> >>>>>> Please check if it is ok, whoever has time/will. >>>>>> >>>>>> Please keep in mind this is preliminary. >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>>> >>>>>> >>>>>> >>>>>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>>>>> >>>>>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>>>>> >>>>>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>>>>> >>>>>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>>>>> >>>>>> Report tomorrow, or so :) >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 25 08:34:13 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Apr 2013 08:34:13 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> Message-ID: <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> On Thu, 25 Apr 2013 07:38:46 +0200 Dragi?a Duri? wrote: > Great idea! > > https://github.com/blog/674-introducing-organizations > > cm3 organization is already created on github, and also modula-3 exists. Ideas? I think the most important question we need to answer first is if and how we should split up the CM3 repository into several smaller ones, i.e. factor out standalone applications and projects like ESC, caltech-parser, m3lectern, m3gdb, etc. I'm not sure if we can do this easily later with git. I'd also like to see some performance numbers for a complete clone and checkout, as this is what several of the regression test jobs will do. Of course the latter can be done based on a local slave repository. I've created a Wiki page to document the migration project in trac at https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration I'd like to encourage everybody to add their ideas and notes there. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu Apr 25 08:51:34 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 25 Apr 2013 08:51:34 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> Message-ID: <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository It looks to me it is thought of in git? Maybe it is not a current priority? -- Dragi?a Duri? dragisha at m3w.org On Apr 25, 2013, at 8:34 AM, Olaf Wagner wrote: > I think the most important question we need to answer first is if and how > we should split up the CM3 repository into several smaller ones, i.e. > factor out standalone applications and projects like ESC, caltech-parser, > m3lectern, m3gdb, etc. > > I'm not sure if we can do this easily later with git. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Thu Apr 25 09:27:40 2013 From: wagner at elego.de (Olaf Wagner) Date: Thu, 25 Apr 2013 09:27:40 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> Message-ID: <20130425092740.55bf536a.wagner@elego.de> On Thu, 25 Apr 2013 08:51:34 +0200 Dragi?a Duri? wrote: > http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository > > It looks to me it is thought of in git? Maybe it is not a current priority? Well, that's something I didn't know about. However, since we need to setup the regression testing anew, or better, move from Hudson to Jenkins at the same time, it may be better to split before we do that. Are there any strong opinions about such a move? Olaf > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 25, 2013, at 8:34 AM, Olaf Wagner wrote: > > > I think the most important question we need to answer first is if and how > > we should split up the CM3 repository into several smaller ones, i.e. > > factor out standalone applications and projects like ESC, caltech-parser, > > m3lectern, m3gdb, etc. > > > > I'm not sure if we can do this easily later with git. > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu Apr 25 10:52:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 25 Apr 2013 10:52:03 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: <20130425092740.55bf536a.wagner@elego.de> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> <20130425092740.55bf536a.wagner@elego.de> Message-ID: On Apr 25, 2013, at 9:27 AM, Olaf Wagner wrote: >> >> http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository >> >> It looks to me it is thought of in git? Maybe it is not a current priority? > > Well, that's something I didn't know about. However, since we need to setup > the regression testing anew, or better, move from Hudson to Jenkins at the > same time, it may be better to split before we do that. > > Are there any strong opinions about such a move? Does a strong support count? :) Also: http://stackoverflow.com/questions/3910412/split-large-git-repository-into-many-smaller-ones So, yes? We can do it in multiple ways. > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 25 15:20:12 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Apr 2013 09:20:12 -0400 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> Message-ID: <20130425132012.GA28811@topoi.pooq.com> On Wed, Apr 24, 2013 at 09:06:32PM -0700, Darko wrote: > You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. > > The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. > > Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. Could the problem be just with NULL-typed variables where the NULL type is not mentioned explicitly in the declaration? These might merit a warning. By the way, what is done with VAR x := 1; Is x implicitly of type 1:1? -- hendrik From rodney_bates at lcwb.coop Thu Apr 25 19:36:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Apr 2013 12:36:11 -0500 Subject: [M3devel] null type? In-Reply-To: <20130425132012.GA28811@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> Message-ID: <5179698B.7020703@lcwb.coop> On 04/25/2013 08:20 AM, Hendrik Boom wrote: > On Wed, Apr 24, 2013 at 09:06:32PM -0700, Darko wrote: >> You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. >> >> The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. >> >> Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. > > Could the problem be just with NULL-typed variables where the NULL type > is not mentioned explicitly in the declaration? > > These might merit a warning. > > By the way, what is done with > VAR x := 1; > No, the type of 1 is INTEGER, and the type of 1L is LONGINT. But you could make something like that happen with CONST OneOnly : [1..1] = 1; VAR x := OneOnly; > Is x implicitly of type 1:1? > > -- hendrik > From rodney_bates at lcwb.coop Thu Apr 25 19:37:38 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Apr 2013 12:37:38 -0500 Subject: [M3devel] null type? In-Reply-To: <20130425132012.GA28811@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> Message-ID: <517969E2.8000702@lcwb.coop> On 04/25/2013 08:20 AM, Hendrik Boom wrote: > On Wed, Apr 24, 2013 at 09:06:32PM -0700, Darko wrote: >> You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. >> >> The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. >> >> Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. > > Could the problem be just with NULL-typed variables where the NULL type > is not mentioned explicitly in the declaration? > > These might merit a warning. > > By the way, what is done with > VAR x := 1; > No, the type of 1 is INTEGER (and the type of 1L is LONGINT). see 2.6.4. But you could make something like that happen with CONST OneOnly : [1..1] = 1; VAR x := OneOnly; > Is x implicitly of type 1:1? > > -- hendrik > From hendrik at topoi.pooq.com Thu Apr 25 20:13:03 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Apr 2013 14:13:03 -0400 Subject: [M3devel] UI libraries Message-ID: <20130425181303.GA31005@topoi.pooq.com> Are there bindings for Modula 3 to use user-interface libraries other than Trestle? If so, are any of those libraries cross-platform? If not, would it be worth writing such a binding? And for which library? -- hendrik From hendrik at topoi.pooq.com Thu Apr 25 20:16:02 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Apr 2013 14:16:02 -0400 Subject: [M3devel] null type? In-Reply-To: <5179698B.7020703@lcwb.coop> References: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> <5179698B.7020703@lcwb.coop> Message-ID: <20130425181602.GB31005@topoi.pooq.com> On Thu, Apr 25, 2013 at 12:36:11PM -0500, Rodney M. Bates wrote: > > > On 04/25/2013 08:20 AM, Hendrik Boom wrote: > > > >Could the problem be just with NULL-typed variables where the NULL type > >is not mentioned explicitly in the declaration? > > > >These might merit a warning. > > > >By the way, what is done with > > VAR x := 1; > > > > No, the type of 1 is INTEGER, and the type of 1L is LONGINT. > > But you could make something like that happen with > CONST OneOnly : [1..1] = 1; > VAR x := OneOnly; Is there some reason why 1 is by default given the maximal type containing 1, whereas NIL is given the minimal type containing NIL? -- hendrik > > >Is x implicitly of type 1:1? > > > >-- hendrik > > > From dmuysers at hotmail.com Thu Apr 25 22:12:23 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Thu, 25 Apr 2013 22:12:23 +0200 Subject: [M3devel] UI libraries In-Reply-To: <20130425181303.GA31005@topoi.pooq.com> References: <20130425181303.GA31005@topoi.pooq.com> Message-ID: If I had the time, I would opt for the IUP portable interface library (http://www.tecgraf.puc-rio.br/iup/) Bindings for that one are particularly easy to make. Only drawback: The next release will implement UTF-8 text for all platforms (the existing version has ASCII for Win32 and UTF-8 for GTK). I would myself like M3 to step back to the good old SRC-PM3 text system (but UTF-8 encoded) preferably to the actual dual CHAR-WCHAR text machinery). I also think that it was Microsoft's biggest mistake to impose 16-bit characters which are still variable length (think of surrogates) without the advantages UTF-8 offers. -------------------------------------------------- From: "Hendrik Boom" Sent: Thursday, April 25, 2013 8:13 PM To: Subject: [M3devel] UI libraries > Are there bindings for Modula 3 to use user-interface libraries other > than Trestle? > > If so, are any of those libraries cross-platform? > > If not, would it be worth writing such a binding? And for which library? > > -- hendrik From rodney_bates at lcwb.coop Thu Apr 25 22:20:02 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Apr 2013 15:20:02 -0500 Subject: [M3devel] null type? In-Reply-To: <20130425181602.GB31005@topoi.pooq.com> References: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> <5179698B.7020703@lcwb.coop> <20130425181602.GB31005@topoi.pooq.com> Message-ID: <51798FF2.8020302@lcwb.coop> On 04/25/2013 01:16 PM, Hendrik Boom wrote: > On Thu, Apr 25, 2013 at 12:36:11PM -0500, Rodney M. Bates wrote: >> >> >> On 04/25/2013 08:20 AM, Hendrik Boom wrote: >>> >>> Could the problem be just with NULL-typed variables where the NULL type >>> is not mentioned explicitly in the declaration? >>> >>> These might merit a warning. >>> >>> By the way, what is done with >>> VAR x := 1; >>> >> >> No, the type of 1 is INTEGER, and the type of 1L is LONGINT. >> >> But you could make something like that happen with >> CONST OneOnly : [1..1] = 1; >> VAR x := OneOnly; > > Is there some reason why 1 is by default given the maximal type > containing 1, whereas NIL is given the minimal type containing NIL? Hmm, that's a good question. I'm just speculating here, but I can think of a couple of things. There is just one NULL in the language, and it is builtin and the same minimum for all reference types, traced and untraced. In contrast, every integer (and enumeration) literal value would have a different minimal type, and these are not builtin types. They would all be implicitly defined by their literal values, creating a lot of stuff floating around the compiler that wouldn't do much, since they would all be statically assignable, wherever referenced. As for making NIL have maximal type, there isn't one in the language now. It would have to include both the traced and untraced hierarchies. Then somebody could declare a variable of that type, giving a need to be able to distinguish the non-NIL values at runtime as traced or not. That would either call for some kind of fat pointer (which there would not be enough bits, in case of UNTRACED REF CHAR) or having every referent have a heap allocator word, which would then undermine using untraced refs for unsafe low-level coding like pointers to things not in any heap. I suppose there could have been separate traced and untraced NILs, but that probably would have gotten major complaints and been much harder to justify than say, 1 vs. 1L, which are necessary for resolution of arithmetic operators. > > -- hendrik > >> >>> Is x implicitly of type 1:1? >>> >>> -- hendrik >>> >> > From dragisha at m3w.org Fri Apr 26 08:08:55 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 26 Apr 2013 08:08:55 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: References: <20130425181303.GA31005@topoi.pooq.com> Message-ID: <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> As for GUI, I have pretty extensive binding for Gtk+, and I am also done some work with gobject-introspection with plans to provide complete binding of everything glib. My plan is to publish it (an older version, for Gtk1, already circulated here). Gtk+ works on almost everything. As for TEXT system? Old TEXT system base type was semiopaque REF ARRAY OF CHAR. Compiler was hooking & to Text.Cat which was "allocate enough space, copy both arguments, keep everything ASCIIZ". New type makes & as efficient as possible, but does not disallow us to reimplement RtHooks' Cat and MultiCat to behave just like 3.6/pm3 Text.Cat. I think cm3's reasoning was pretty natural once they decided (because of task at hand, JVM) to create WIDECHAR as standard type. Next was W"" literal, and one thing was following another. When this proved itself as efficient for their needs, it was cemented. I would like to know if anybody would object to reimplementation of TextCat module? I can make it, no problem, as people are not going to lynch me :). Dirk, are you covering Unicode Collate with your Unicode implementation? Except for Unicode tables (and your earlier implementation of this is very useful) and UTF handling/operations (I have this, very complete), Unicode Collate remain biggest remaining obstacle for full incorporation of Unicode/UTF8 into cm3. dd On Apr 25, 2013, at 10:12 PM, Dirk Muysers wrote: > I would myself like M3 to step back to the good old > SRC-PM3 text system (but UTF-8 encoded) > preferably to the actual dual CHAR-WCHAR text > machinery). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri Apr 26 11:17:59 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 26 Apr 2013 11:17:59 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> Message-ID: >> Dirk, are you covering Unicode Collate with your Unicode implementation? Except for Unicode >> tables (and your earlier implementation of this is very useful) and UTF handling/operations >> (I have this, very complete), Unicode Collate remain biggest remaining obstacle for full incorporation >> of Unicode/UTF8 into cm3. Full Unicode collation implies normalization and a lot more tables (and tools to extract these tables from the Unicode data base) The only libraries I know about that do it are the (rather monstruous) IBM library and, to a certain extent, glib. Even go(lang) doesn't offer it. Normal comparison associated with simple case folding (which is part of my library) is a first step in that direction. Simple case folding folds only 1:1 UC/LC pairs. The emblematic special case being German eszet that folds to SS, but even that case is now covered by the inclusion of a special eszet upper case glyph in recent Unicode releases, so that most European languages are now covered. Languages that still need special processing are the Turkic family (Turkish and Azeri). So, as long as one compares only own text files (which do not mingle accented glyphs and decomposed glyphs), one gets an acceptable collation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 26 21:37:18 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 26 Apr 2013 14:37:18 -0500 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> Message-ID: <517AD76E.9090007@lcwb.coop> On 04/26/2013 01:08 AM, Dragi?a Duri? wrote: > As for GUI, I have pretty extensive binding for Gtk+, and I am also done some work with gobject-introspection with plans to provide complete binding of everything glib. My plan is to publish it (an older version, for Gtk1, already circulated here). Gtk+ works on almost everything. > > As for TEXT system? Old TEXT system base type was semiopaque REF ARRAY OF CHAR. Compiler was hooking & to Text.Cat which was "allocate enough space, copy both arguments, keep everything ASCIIZ". New type makes & as efficient as possible, but does not disallow us to reimplement RtHooks' Cat and MultiCat to behave just like 3.6/pm3 Text.Cat. > Two or three years ago, I wrote a revised system that lies somewhere between the compromises of PM3 and CM3 Text operations. It uses the same data structure and invariants as the CM3 system, so any values it produces are consistent with existing CM3-compiled code. It partially flattens concatenated strings, as in PM3, up to a point. It also does some heuristic approximate rebalancing of concatenated trees. Between these, it achieves some significant performance advantages, though it loses some in certain cases. Both the PM3 and the CM3 system have performance problems when a Text is built up linearly, left-to-right (or right-to-left) from single characters or short fragments. This is a very common pattern. PM3 makes concatenation O(N), but accessing is O(1). CM3 is the opposite. Concatenation is O(1) but O(N) in accessing individual characters and substrings. CM3 also uses somewhere around an order of magnitude more memory for linearly-concatenated strings. I posted a bunch of empirical performance numbers on this list, showing some of the tradeoffs of my intermediate implementation. I think it would represent a good middle ground. Barring that, I too would go back to the PM3 scheme, as the storage use and access time of the original CM3 scheme can be pretty awful. It never got put into the repository because I had the means to test only for LINUXLIBC6 and AMD64_LINUX. It is pretty thoroughly tested on those platforms. It's hard to imagine target-dependent bugs, but who hasn't been wrong about that before? Perhaps we could get its test program into the automated system on the many platforms, then consider using it. > I think cm3's reasoning was pretty natural once they decided (because of task at hand, JVM) to create WIDECHAR as standard type. Next was W"" literal, and one thing was following another. When this proved itself as efficient for their needs, it was cemented. > > I would like to know if anybody would object to reimplementation of TextCat module? I can make it, no problem, as people are not going to lynch me :). > > Dirk, are you covering Unicode Collate with your Unicode implementation? Except for Unicode tables (and your earlier implementation of this is very useful) and UTF handling/operations (I have this, very complete), Unicode Collate remain biggest remaining obstacle for full incorporation of Unicode/UTF8 into cm3. > > dd > > On Apr 25, 2013, at 10:12 PM, Dirk Muysers wrote: > >> I would myself like M3 to step back to the good old >> SRC-PM3 text system (but UTF-8 encoded) >> preferably to the actual dual CHAR-WCHAR text >> machinery). > From dragisha at m3w.org Fri Apr 26 23:21:59 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 26 Apr 2013 23:21:59 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <517AD76E.9090007@lcwb.coop> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> <517AD76E.9090007@lcwb.coop> Message-ID: <3B35444C-3155-41E4-9714-F39DC5BFF1CD@m3w.org> Original PM3 scheme is a bit too much back :), being non OO. Objectness of TEXT has its uses. I think your scheme can be incorporated as an alternative, selectable during m3core build, without much problem. I would like to try it. On Apr 26, 2013, at 9:37 PM, Rodney M. Bates wrote: > I posted a bunch of empirical performance numbers on this list, showing some of the tradeoffs > of my intermediate implementation. I think it would represent a good middle ground. Barring > that, I too would go back to the PM3 scheme, as the storage use and access time of the original > CM3 scheme can be pretty awful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 26 23:49:39 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Apr 2013 23:49:39 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <3B35444C-3155-41E4-9714-F39DC5BFF1CD@m3w.org> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> <517AD76E.9090007@lcwb.coop> <3B35444C-3155-41E4-9714-F39DC5BFF1CD@m3w.org> Message-ID: <20130426234939.60d0f292b878b9e65b98441b@elegosoft.com> On Fri, 26 Apr 2013 23:21:59 +0200 Dragi?a Duri? wrote: > Original PM3 scheme is a bit too much back :), being non OO. Objectness of TEXT has its uses. > > I think your scheme can be incorporated as an alternative, selectable during m3core build, without much problem. I would like to try it. I'd also vote to give Rodney's code a try. Olaf > On Apr 26, 2013, at 9:37 PM, Rodney M. Bates wrote: > > > I posted a bunch of empirical performance numbers on this list, showing some of the tradeoffs > > of my intermediate implementation. I think it would represent a good middle ground. Barring > > that, I too would go back to the PM3 scheme, as the storage use and access time of the original > > CM3 scheme can be pretty awful. -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sun Apr 28 20:09:32 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 28 Apr 2013 20:09:32 +0200 Subject: [M3devel] Issues with gcc backend optimizations, any? Message-ID: I remember we had issues with optimizations turned on. Is it safe to use now? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Sun Apr 28 23:03:30 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Apr 2013 14:03:30 -0700 Subject: [M3devel] configure_system_libs In-Reply-To: <20130428190606.3DF769BA007@birch.elegosoft.com> References: <20130428190606.3DF769BA007@birch.elegosoft.com> Message-ID: I probably handle this in cm3.cfg. But you are probably mixing new tree with old config... - Jay On Apr 28, 2013, at 2:06 PM, "Rodney M. Bates" wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/04/28 21:06:06 > > Modified files: > cm3/m3-db/odbc/test/src/: m3makefile > ./: m3makefile > cm3/m3-db/pgodbc/src/: m3makefile > ./: m3makefile > cm3/m3-db/postgres95/test/src/: m3makefile > ./: m3makefile > cm3/m3-games/columns/src-x11/: m3makefile > ./: m3makefile > cm3/m3-games/tetris/src/: m3makefile > ./: m3makefile > cm3/m3-tools/cvsup/suplib/src/: m3makefile > ./: m3makefile > cm3/m3-tools/gnuemacs/src/: m3makefile > ./: m3makefile > cm3/m3-tools/pp/src/: m3makefile > ./: m3makefile > cm3/m3-ui/PEX/src/: m3makefile > ./: m3makefile > cm3/m3-ui/X11R4/src/: m3makefile > ./: m3makefile > cm3/m3-ui/anim3D/src/: m3makefile > ./: m3makefile > cm3/m3-ui/motif/src/: m3makefile > ./: m3makefile > cm3/m3-ui/opengl/src/: m3makefile > ./: m3makefile > cm3/m3-ui/ui/src/xvbt/: m3makefile > > Log message: > Many packages were failing to build, with: > > quake runtime error: undefined variable: configure_system_libs > > at least on LINUXLIBC6. Make the call on configure_system_libs in these > m3makefiles conditional on its being defined, as they already were in the > m3makefiles in several other packages. > From dragisha at m3w.org Tue Apr 30 07:42:44 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Apr 2013 07:42:44 +0200 Subject: [M3devel] thread local storage, but in C pieces of runtime... (jay, tony?) Message-ID: <8489B8D9-9442-4EE1-940F-4C69B96AF61B@m3w.org> Is there a specific reason why TLS is done through C, and not through pthread.(set|get)specific? dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hosking at cs.purdue.edu Tue Apr 30 09:21:50 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 30 Apr 2013 17:21:50 +1000 Subject: [M3devel] thread local storage, but in C pieces of runtime... (jay, tony?) In-Reply-To: <8489B8D9-9442-4EE1-940F-4C69B96AF61B@m3w.org> References: <8489B8D9-9442-4EE1-940F-4C69B96AF61B@m3w.org> Message-ID: <80EA00C3-AACC-472D-A43B-E2121CBD4AAB@cs.purdue.edu> I used to use pthread specifics but I think jay changed it to C. Not sure why unless compiler can generate more efficiently via sp hacks. Sent from my iPhone On 30/04/2013, at 3:42 PM, Dragi?a Duri? wrote: > Is there a specific reason why TLS is done through C, and not through pthread.(set|get)specific? > > dd > > -- > Dragi?a Duri? > dragisha at m3w.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 30 09:23:17 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 30 Apr 2013 17:23:17 +1000 Subject: [M3devel] Fwd: thread local storage, but in C pieces of runtime... (jay, tony?) References: <80EA00C3-AACC-472D-A43B-E2121CBD4AAB@cs.purdue.edu> Message-ID: <695CFD6E-FE05-4CAC-99DD-18D8B5CCCE26@cs.purdue.edu> Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: 30 April 2013 5:21:50 PM AEST > To: Dragi?a Duri? > Cc: m3devel developers > Subject: Re: [M3devel] thread local storage, but in C pieces of runtime... (jay, tony?) > > I used to use pthread specifics but I think jay changed it to C. Not sure why unless compiler can generate more efficiently via sp hacks. > > Sent from my iPhone > > On 30/04/2013, at 3:42 PM, Dragi?a Duri? wrote: > >> Is there a specific reason why TLS is done through C, and not through pthread.(set|get)specific? >> >> dd >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 30 17:43:50 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 30 Apr 2013 10:43:50 -0500 Subject: [M3devel] configure_system_libs In-Reply-To: References: <20130428190606.3DF769BA007@birch.elegosoft.com> Message-ID: <517FE6B6.2020809@lcwb.coop> On 04/28/2013 04:03 PM, Jay wrote: > I probably handle this in cm3.cfg. > But you are probably mixing new tree with old config... > > I am building a freshly-updated head, using the most recent release, without modification, to do it. That should always work. > - Jay > > On Apr 28, 2013, at 2:06 PM, "Rodney M. Bates" wrote: > >> CVSROOT: /usr/cvs >> Changes by: rodney at birch. 13/04/28 21:06:06 >> >> Modified files: >> cm3/m3-db/odbc/test/src/: m3makefile >> ./: m3makefile >> cm3/m3-db/pgodbc/src/: m3makefile >> ./: m3makefile >> cm3/m3-db/postgres95/test/src/: m3makefile >> ./: m3makefile >> cm3/m3-games/columns/src-x11/: m3makefile >> ./: m3makefile >> cm3/m3-games/tetris/src/: m3makefile >> ./: m3makefile >> cm3/m3-tools/cvsup/suplib/src/: m3makefile >> ./: m3makefile >> cm3/m3-tools/gnuemacs/src/: m3makefile >> ./: m3makefile >> cm3/m3-tools/pp/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/PEX/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/X11R4/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/anim3D/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/motif/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/opengl/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/ui/src/xvbt/: m3makefile >> >> Log message: >> Many packages were failing to build, with: >> >> quake runtime error: undefined variable: configure_system_libs >> >> at least on LINUXLIBC6. Make the call on configure_system_libs in these >> m3makefiles conditional on its being defined, as they already were in the >> m3makefiles in several other packages. >> > From darko at darko.org Mon Apr 1 23:53:37 2013 From: darko at darko.org (Darko) Date: Mon, 1 Apr 2013 14:53:37 -0700 Subject: [M3devel] Why do we need external debugging? Message-ID: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko From dabenavidesd at yahoo.es Tue Apr 2 05:42:39 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 2 Apr 2013 04:42:39 +0100 (BST) Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <1364874159.80556.YahooMailClassic@web172803.mail.ir2.yahoo.com> Hi all: yes, the VAX900 mainframe had this capability, of executing the code an same time verifying its operation results. Would like to make a RT in that way, but it shouldn't be that hard, should be? Thanks in advance PS: BTW I just had an idea today, make the experiment in DEC-SRC of DISPOSABLE memory information safe, so making some adjustments to the type system, with coercion and other soft typing stuff make the language type safe entirely, We would need just suppress the annoying word UNSAFE of all modules, and make the language 100% machine checkable. At the same time introducing functional objects, like in bay Modula-3 , to able to model the language in that way. Thanks in advance --- El lun, 1/4/13, Darko escribi?: De: Darko Asunto: [M3devel] Why do we need external debugging? Para: "m3devel developers" Fecha: lunes, 1 de abril, 2013 16:53 The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Apr 2 06:02:15 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 2 Apr 2013 05:02:15 +0100 (BST) Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1364874159.80556.YahooMailClassic@web172803.mail.ir2.yahoo.com> Message-ID: <1364875335.9036.YahooMailClassic@web172805.mail.ir2.yahoo.com> Hi all: an old known in this list wrote me today precisely about need of source level debuggers and builtin-debuggers in MacApp API in Pascal years: ? http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2013/3/30_Building_Photoshop.html read the last and before last paragraph (sounds like we would need language modification to support this kind of debugger) Thanks in advance --- El lun, 1/4/13, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] Why do we need external debugging? Para: "m3devel developers" , "Darko" Fecha: lunes, 1 de abril, 2013 22:42 Hi all: yes, the VAX900 mainframe had this capability, of executing the code an same time verifying its operation results. Would like to make a RT in that way, but it shouldn't be that hard, should be? Thanks in advance PS: BTW I just had an idea today, make the experiment in DEC-SRC of DISPOSABLE memory information safe, so making some adjustments to the type system, with coercion and other soft typing stuff make the language type safe entirely, We would need just suppress the annoying word UNSAFE of all modules, and make the language 100% machine checkable. At the same time introducing functional objects, like in bay Modula-3 , to able to model the language in that way. Thanks in advance --- El lun, 1/4/13, Darko escribi?: De: Darko Asunto: [M3devel] Why do we need external debugging? Para: "m3devel developers" Fecha: lunes, 1 de abril, 2013 16:53 The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 2 06:22:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Apr 2013 04:22:12 +0000 Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: External debuggers are good. Have you used Visual Studio much? Generate the right debug information and we get excellent working debuggers that people put a lot of time and work into. On the other hand, I do understand your notion of "internal debugger" and agree it is a good approach. - Jay > From: darko at darko.org > Date: Mon, 1 Apr 2013 14:53:37 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Why do we need external debugging? > > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > Am I the only one who thinks this? > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Apr 2 06:44:02 2013 From: darko at darko.org (Darko) Date: Mon, 1 Apr 2013 21:44:02 -0700 Subject: [M3devel] Why do we need external debugging? In-Reply-To: References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: Can't say I like VS, though I have used it. I didn't really use any of the features except the stack dump. For a language like M3 internal debugging makes a lot of sense since it's unlikely to affect anything else, and I like the idea of being able to customize it for my own purposes while maintaining performance. Maybe a simple object based "plug in" architecture would work well. On Apr 1, 2013, at 9:22 PM, Jay K wrote: > External debuggers are good. Have you used Visual Studio much? > Generate the right debug information and we get excellent working debuggers that people put a lot of time and work into. > > > On the other hand, I do understand your notion of "internal debugger" and agree it is a good approach. > > > - Jay > > > > > From: darko at darko.org > > Date: Mon, 1 Apr 2013 14:53:37 -0700 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Why do we need external debugging? > > > > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > > > Am I the only one who thinks this? > > > > - Darko > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 2 15:08:26 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 2 Apr 2013 09:08:26 -0400 Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <20130402130826.GB16617@topoi.pooq.com> On Mon, Apr 01, 2013 at 02:53:37PM -0700, Darko wrote: > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > Am I the only one who thinks this? Internal debuggers are great for programs that are written all in one language. But not so great when multiple languages are involved. Unfortunately, the debuggers we have don't seem to have evolved to exhibit the interfaces needed for source languages significantly different from C. C-- has primitives for stack-walking, on which a debugging-style stack-walker could be built, but even here there's no canonical way to provide variable-name information and the like. -- hendrik From darko at darko.org Tue Apr 2 19:51:48 2013 From: darko at darko.org (Darko) Date: Tue, 2 Apr 2013 10:51:48 -0700 Subject: [M3devel] Internal debugging - a simple design Message-ID: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Here's an idea for how simple internal debugging might work. A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): CONST ProcName: TEXT = "Module.ProcName"; ProcType: CARDINAL = 12345678; ProcAdr: ADDRESS = 123456; ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); ReturnType: CARDINAL = 12345678; ReturnOffs: INTEGER = 32; LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: PROCEDURE DebugProcEntry( READONLY frame: ADDRESS; READONLY procName: ProcName; READONLY procType: ProcType; READONLY procAdr: ProcAdr; READONLY paramNames: ParamNames; READONLY paramTypes: ParamTypes; READONLY paramOffs: ParamOffs; READONLY returnType: ReturnType; READONLY returnOffs: ReturnOffs; READONLY localNames: LocalNames; READONLY localTypes: LocalTypes; READONLY localOffs: LocalOffs ); Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. - Darko From jay.krell at cornell.edu Wed Apr 3 00:39:09 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Apr 2013 22:39:09 +0000 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Message-ID: I don't want to have to recompile anything. Ideally the overhead of the debug stuff is low enough that it is always on. That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. I believe you need to make a function call for every line or "instruction". That is the hook for stepping and breakpoints. You need function calls to the debugger for every assignment. If you have something like "watch breakpoints" ("Break whenv variable x becomes 123.") On the assignment matter though, it could be done in the step/instruction call. There isn't necessarily a zero offset for parameters and locals.. well..a debug system probably creates one..homing all the parameters and not enregistering everything..You should probably bundle up the data into a smaller number of linked structures, in order to pass fewer parameters to DebugProcEntry. Beware module globals also. Even in my upcoming C backend work, they don't work well. I think that needs frontend work. :( - Jay > From: darko at darko.org > Date: Tue, 2 Apr 2013 10:51:48 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Internal debugging - a simple design > > Here's an idea for how simple internal debugging might work. > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > CONST > ProcName: TEXT = "Module.ProcName"; > ProcType: CARDINAL = 12345678; > ProcAdr: ADDRESS = 123456; > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > ReturnType: CARDINAL = 12345678; > ReturnOffs: INTEGER = 32; > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > PROCEDURE DebugProcEntry( > READONLY frame: ADDRESS; > READONLY procName: ProcName; > READONLY procType: ProcType; > READONLY procAdr: ProcAdr; > READONLY paramNames: ParamNames; > READONLY paramTypes: ParamTypes; > READONLY paramOffs: ParamOffs; > READONLY returnType: ReturnType; > READONLY returnOffs: ReturnOffs; > READONLY localNames: LocalNames; > READONLY localTypes: LocalTypes; > READONLY localOffs: LocalOffs > ); > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 3 02:45:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 00:45:23 +0000 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> , <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> Message-ID: > along with a special number for registers and pesudo-functions I missed that, sorry, by skimming. Be sure to use very large but not negative numbers..as negative numbersmight be actual offsets.. > Beware module globals also. > I think they're rare enough that I disagree strongly. I'd really like to fix this too, at least put fields in the "segments" to give backends a chance... Again, though, I don't want to change and recompile anything to debug. Just like normal code. If I'm going to recompile..well, then RTIO.PutText/printf/OutputDebugStringA/DbgPrint like crazy. Sadly, I do a lot of that. Other than an external file, compilers have support for "sections" -- you can put the "cold" code/data "out of the way", but in the same file.There are tradeoffs either way.External files are the way on Windows and increasingly the way on Unix.But then you have to somehow find the file."Internal" is great for ease of finding. Some systems (VMS) keep a minimal amount in the code, and I guess, the rest outside. > Recompile time is quick compared to the overhead this would introduce. The idea is to debug w/o source and compiler.But it is a slippery slope. Full "internal debugging" puts "almost" the source in the executable.Is source absent because it is secret? or large? Or always present? - Jay Subject: Re: [M3devel] Internal debugging - a simple design From: darko at darko.org Date: Tue, 2 Apr 2013 15:54:41 -0700 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On Apr 2, 2013, at 3:39 PM, Jay K wrote:I don't want to have to recompile anything. Ideally the overhead of the debug stuff is low enough that it is always on. That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size. I believe you need to make a function call for every line or "instruction". That is the hook for stepping and breakpoints. I don't think this is required. If you want to break you put in a call in your code. Recompile time is quick compared to the overhead this would introduce. You need function calls to the debugger for every assignment. If you have something like "watch breakpoints" ("Break whenv variable x becomes 123.") On the assignment matter though, it could be done in the step/instruction call. Again, if you want this you put a call in your code, just like the existing pragma. There isn't necessarily a zero offset for parameters and locals.. well..a debug system probably creates one..homing all the parameters and not enregistering everything.. You should probably bundle up the data into a smaller number of linked structures, in order to pass fewer parameters to DebugProcEntry. Notice the offset is an integer, along with a special number for registers and pesudo-functions to access them, wouldn't that avoid changes for debugging? Beware module globals also. Even in my upcoming C backend work, they don't work well. I think that needs frontend work. :( I think they're rare enough that they could be handled with functions instead of this debugging code. - Jay > From: darko at darko.org > Date: Tue, 2 Apr 2013 10:51:48 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Internal debugging - a simple design > > Here's an idea for how simple internal debugging might work. > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > CONST > ProcName: TEXT = "Module.ProcName"; > ProcType: CARDINAL = 12345678; > ProcAdr: ADDRESS = 123456; > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > ReturnType: CARDINAL = 12345678; > ReturnOffs: INTEGER = 32; > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > PROCEDURE DebugProcEntry( > READONLY frame: ADDRESS; > READONLY procName: ProcName; > READONLY procType: ProcType; > READONLY procAdr: ProcAdr; > READONLY paramNames: ParamNames; > READONLY paramTypes: ParamTypes; > READONLY paramOffs: ParamOffs; > READONLY returnType: ReturnType; > READONLY returnOffs: ReturnOffs; > READONLY localNames: LocalNames; > READONLY localTypes: LocalTypes; > READONLY localOffs: LocalOffs > ); > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 3 00:54:41 2013 From: darko at darko.org (Darko) Date: Tue, 2 Apr 2013 15:54:41 -0700 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Message-ID: <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> On Apr 2, 2013, at 3:39 PM, Jay K wrote: > I don't want to have to recompile anything. > Ideally the overhead of the debug stuff is low enough that it is always on. > That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size. > I believe you need to make a function call for every line or "instruction". > That is the hook for stepping and breakpoints. I don't think this is required. If you want to break you put in a call in your code. Recompile time is quick compared to the overhead this would introduce. > You need function calls to the debugger for every assignment. > If you have something like "watch breakpoints" > ("Break whenv variable x becomes 123.") > On the assignment matter though, it could be done in the step/instruction call. Again, if you want this you put a call in your code, just like the existing pragma. > There isn't necessarily a zero offset for parameters and locals.. > well..a debug system probably creates one..homing all the parameters > and not enregistering everything.. > You should probably bundle up the data into a smaller number of linked structures, > in order to pass fewer parameters to DebugProcEntry. Notice the offset is an integer, along with a special number for registers and pesudo-functions to access them, wouldn't that avoid changes for debugging? > > > Beware module globals also. > Even in my upcoming C backend work, they don't work well. > I think that needs frontend work. :( > I think they're rare enough that they could be handled with functions instead of this debugging code. > > - Jay > > > > > > From: darko at darko.org > > Date: Tue, 2 Apr 2013 10:51:48 -0700 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Internal debugging - a simple design > > > > Here's an idea for how simple internal debugging might work. > > > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > > > CONST > > ProcName: TEXT = "Module.ProcName"; > > ProcType: CARDINAL = 12345678; > > ProcAdr: ADDRESS = 123456; > > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > > ReturnType: CARDINAL = 12345678; > > ReturnOffs: INTEGER = 32; > > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > > > PROCEDURE DebugProcEntry( > > READONLY frame: ADDRESS; > > READONLY procName: ProcName; > > READONLY procType: ProcType; > > READONLY procAdr: ProcAdr; > > READONLY paramNames: ParamNames; > > READONLY paramTypes: ParamTypes; > > READONLY paramOffs: ParamOffs; > > READONLY returnType: ReturnType; > > READONLY returnOffs: ReturnOffs; > > READONLY localNames: LocalNames; > > READONLY localTypes: LocalTypes; > > READONLY localOffs: LocalOffs > > ); > > > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > > > - Darko > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 3 04:51:15 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 2 Apr 2013 22:51:15 -0400 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> Message-ID: <20130403025115.GA30084@topoi.pooq.com> On Wed, Apr 03, 2013 at 12:45:23AM +0000, Jay K wrote: > Again, though, I don't want to change and recompile anything to debug. Then an interpreter could be your friend. > The idea is to debug w/o source and compiler.But it is a slippery > slope. Full "internal debugging" puts "almost" the source in the > executable.Is source absent because it is secret? or large? Or always > present? The old Algol W compiler on the IBM 360 could be asked to place a trimmed-down copy of the source code somewhere (in memory if I recall correctly). It would contain bytecodes for reserved words and operators, indexes into a symbol table for identifiers, and the like. Then every time execution would enter a basic block, it would increment a counter -- one counter for each basic block. When execution finished, it would prepare a printout, expanding all those brief byte codes and indices, indenting properly, and printing the count beside the start of every basic block. I would debug from this listing and suppress the usual source-code listing. This count-annotated listing was much more useful. -- hendrik From jay.krell at cornell.edu Wed Apr 3 10:46:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 08:46:10 +0000 Subject: [M3devel] cost of opaque types Message-ID: cost of opaque types fyi: PutI(cstr("Public.F1.a.c"), a.c); PutI == put_adr L_22_L_23 the string L_26_L_27 == a 8 is the "public offset" of c M_Public_L_19 globals for Public.m3 everything else is the computation of the "public base" of a from the base of a actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); simplify slightly (how I wish it got printed...): put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); I still have to track down the whole "recompile again now that offsets are known" path. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 3 15:03:31 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 3 Apr 2013 15:03:31 +0200 Subject: [M3devel] cost of opaque types In-Reply-To: References: Message-ID: <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> There are languages, C# and Java coming to mind? where people accept a lot more from language/compiler for various reasons. :) -- Dragi?a Duri? dragisha at m3w.org On Apr 3, 2013, at 10:46 AM, Jay K wrote: > cost of opaque types > > > fyi: > > PutI(cstr("Public.F1.a.c"), a.c); > > > PutI == put_adr > L_22_L_23 the string > L_26_L_27 == a > 8 is the "public offset" of c > M_Public_L_19 globals for Public.m3 > > > everything else is the computation of the "public base" of a from the base of a > > > actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c > > > put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); > > > simplify slightly (how I wish it got printed...): > > put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); > > > > I still have to track down the whole "recompile again now that offsets are known" path. > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 3 20:53:40 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 03 Apr 2013 11:53:40 -0700 Subject: [M3devel] Why do we need external debugging? In-Reply-To: References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <20130403185340.DC3811A207D@async.async.caltech.edu> All my bigger Modula-3 programs these days include a Scheme interpreter that understands most types in the language... it's not too far from a debugger. Mika Darko writes: > >--Apple-Mail-19-23585903 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=us-ascii > >Can't say I like VS, though I have used it. I didn't really use any of = >the features except the stack dump. For a language like M3 internal = >debugging makes a lot of sense since it's unlikely to affect anything = >else, and I like the idea of being able to customize it for my own = >purposes while maintaining performance. Maybe a simple object based = >"plug in" architecture would work well. > > >On Apr 1, 2013, at 9:22 PM, Jay K wrote: > >> External debuggers are good. Have you used Visual Studio much? >> Generate the right debug information and we get excellent working = >debuggers that people put a lot of time and work into. >>=20 >>=20 >> On the other hand, I do understand your notion of "internal debugger" = >and agree it is a good approach. >>=20 >>=20 >> - Jay >>=20 >>=20 >>=20 >> > From: darko at darko.org >> > Date: Mon, 1 Apr 2013 14:53:37 -0700 >> > To: m3devel at elegosoft.com >> > Subject: [M3devel] Why do we need external debugging? >> >=20 >> > The last time I used an external or lowish-level debugger was the = >last time I programmed in a language other than M3. I find the language = >so safe and reliable that I don't quite understand the need for external = >debuggers. Is it driven by a need to integrate with other languages or = >external libraries? >> >=20 >> > Why can't a debugger be optionally compiled into the code and = >supported by the runtime? I find I don't need much more than the ability = >to log procedure execution, procedure parameters and local variables. I = >imagine some sort of debugging mode with a simple command line and an = >interrupt mechanism would facilitate interactive debugging. >> >=20 >> > Am I the only one who thinks this? >> >=20 >> > - Darko >> >=20 > > >--Apple-Mail-19-23585903 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=us-ascii > >-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Can't = >say I like VS, though I have used it. I didn't really use any of the = >features except the stack dump. For a language like M3 internal = >debugging makes a lot of sense since it's unlikely to affect anything = >else, and I like the idea of being able to customize it for my own = >purposes while maintaining performance. Maybe a simple object based = >"plug in" architecture would work = >well.


On Apr 1, 2013, at 9:22 PM, Jay K = >wrote:

type=3D"cite">separate; font-family: Helvetica; font-style: normal; font-variant: = >normal; font-weight: normal; letter-spacing: normal; line-height: = >normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = >text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
class=3D"hmmessage" style=3D"font-size: 12pt; font-family: Calibri; = >">
External debuggers are good. Have you used Visual = >Studio much?
Generate the right debug information and we get = >excellent working debuggers that people put a lot of time and work = >into.


On the other hand, I do understand your notion of = >"internal debugger" and agree it is a good approach.


 - = >Jay



> = >From: href=3D"mailto:darko at darko.org">darko at darko.org
> Date: Mon, 1 = >Apr 2013 14:53:37 -0700
> To:class=3D"Apple-converted-space"> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = >Subject: [M3devel] Why do we need external debugging?
>class=3D"Apple-converted-space"> 
> The last time I = >used an external or lowish-level debugger was the last time I programmed = >in a language other than M3. I find the language so safe and reliable = >that I don't quite understand the need for external debuggers. Is it = >driven by a need to integrate with other languages or external = >libraries?
>class=3D"Apple-converted-space"> 
> Why can't a = >debugger be optionally compiled into the code and supported by the = >runtime? I find I don't need much more than the ability to log procedure = >execution, procedure parameters and local variables. I imagine some sort = >of debugging mode with a simple command line and an interrupt mechanism = >would facilitate interactive debugging.
>class=3D"Apple-converted-space"> 
> Am I the only one = >who thinks this?
>class=3D"Apple-converted-space"> 
> - = >Darko
>class=3D"Apple-converted-space"> 
= >

= > >--Apple-Mail-19-23585903-- From dragisha at m3w.org Wed Apr 3 23:54:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 3 Apr 2013 23:54:23 +0200 Subject: [M3devel] UTF8, a three zeros library Message-ID: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Zero UNSAFE, zero libc, zero C. https://dl.dropbox.com/u/60554338/UTF8.zip I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8? Suggestions are welcome. And criticism is not unwelcome :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Thu Apr 4 00:26:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 22:26:10 +0000 Subject: [M3devel] cost of opaque types In-Reply-To: <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> References: , <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> Message-ID: If my opaque type exposes no public data, only functions, then I think I'll win significantly by just using "fully transparent prefix object types". I have to check if method calls incur a similar extra overhead. You know, if you have: TYPE T <: OBJECT METHODS F1(); END;NEW(T); vs. interfaceTYPE T = OBJECT METHODS F1(); END; module TYPE TImpl = T OBJECT more stuff END;PROCEDURE CreateT():T = BEGIN RETURN NEW(TImpl); END CreateT; the level of opacity is the same, but the second form likely has much lower overhead. The difference being that you can't directly NEW the type, you have to use a special creator function. Debugging might might might be better in the first case, esp. with stock debuggers, if the backend has or finds enough information (imagine -- backend doesn't really have to be unit-at-a-time..it can sit around building everything in memory..waiting for all the type revelations..and generate everything into one C or .asm or whatever file...) That is, the second case is common in C++ a la COM, and debuggers often only show a vtable and function pointers -- the base type. They ought to figure out from the vtable the leaf type and show everything..maybe Visual Studio does..I use windbg more... - Jay Subject: Re: [M3devel] cost of opaque types From: dragisha at m3w.org Date: Wed, 3 Apr 2013 15:03:31 +0200 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu There are languages, C# and Java coming to mind. where people accept a lot more from language/compiler for various reasons. :) --Dragi?a Duri?dragisha at m3w.org On Apr 3, 2013, at 10:46 AM, Jay K wrote:cost of opaque types fyi: PutI(cstr("Public.F1.a.c"), a.c); PutI == put_adr L_22_L_23 the string L_26_L_27 == a 8 is the "public offset" of c M_Public_L_19 globals for Public.m3 everything else is the computation of the "public base" of a from the base of a actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); simplify slightly (how I wish it got printed...): put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); I still have to track down the whole "recompile again now that offsets are known" path. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 4 00:20:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 22:20:33 +0000 Subject: [M3devel] UTF8, a three zeros library In-Reply-To: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Message-ID: attached my UTF8 library.. clear, simple, Czero libc, zero Modula-3 :) - Jay From: dragisha at m3w.org Date: Wed, 3 Apr 2013 23:54:23 +0200 To: m3devel at elegosoft.com Subject: [M3devel] UTF8, a three zeros library Zero UNSAFE, zero libc, zero C. https://dl.dropbox.com/u/60554338/UTF8.zip I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8. Suggestions are welcome. And criticism is not unwelcome :). --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: utf8.c URL: From dragisha at m3w.org Thu Apr 4 00:28:58 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 4 Apr 2013 00:28:58 +0200 Subject: [M3devel] UTF8, a three zeros library In-Reply-To: References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Message-ID: Great code? maybe a bit short on readability side? :) -- Dragi?a Duri? dragisha at m3w.org On Apr 4, 2013, at 12:20 AM, Jay K wrote: > attached my UTF8 library.. > > clear, simple, C > zero libc, zero Modula-3 :) > > > - Jay > From: dragisha at m3w.org > Date: Wed, 3 Apr 2013 23:54:23 +0200 > To: m3devel at elegosoft.com > Subject: [M3devel] UTF8, a three zeros library > > Zero UNSAFE, zero libc, zero C. > > https://dl.dropbox.com/u/60554338/UTF8.zip > > I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8. > > Suggestions are welcome. And criticism is not unwelcome :). > -- > Dragi?a Duri? > dragisha at m3w.org > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 6 20:40:01 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 6 Apr 2013 20:40:01 +0200 Subject: [M3devel] NARROW(refanyValue, procedureType) Message-ID: Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? new source -> compiling XLModule.m3 "../src/XLModule.m3", line 181: NARROW: types must be assignable "../src/XLModule.m3", line 239: incompatible types (x) Second one is RefSeq.T.addhi(procedureType) TIA, dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mika at async.caltech.edu Sat Apr 6 22:51:45 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 06 Apr 2013 13:51:45 -0700 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: References: Message-ID: <20130406205145.6F2641A207D@async.async.caltech.edu> I think it works as long as you define a (fully specified) wrapper type. e.g., TYPE P = PROCEDURE (x, y : INTEGER) : INTEGER; W = REF RECORD p : P END; ... PROCEDURE Add(x, y : INTEGER) : INTEGER = ... TextWTbl wtbl... wtbl.put("add", NEW(W, p := Add)); ... =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF >Content-Type: multipart/alternative; > boundary="Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4" > > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=utf-8 > >Is this possible in any way? Can I use any Sequence/Table type to hold = >procedure typed values inside? > >new source -> compiling XLModule.m3 >"../src/XLModule.m3", line 181: NARROW: types must be assignable >"../src/XLModule.m3", line 239: incompatible types (x) > >Second one is RefSeq.T.addhi(procedureType) > >TIA, >dd >-- >Dragi=C5=A1a Duri=C4=87 >dragisha at m3w.org > > > > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=utf-8 > >-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Is = >this possible in any way? Can I use any Sequence/Table type to hold = >procedure typed values inside?

new source -> = >compiling XLModule.m3
"../src/XLModule.m3", line 181: NARROW: = >types must be assignable
"../src/XLModule.m3", line 239: = >incompatible types (x)

Second one is = >RefSeq.T.addhi(procedureType)

TIA,
dddiv>
>
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = >Helvetica; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; orphans: 2; = >text-align: -webkit-auto; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; = >">
--
style=3D"font-family: Helvetica; ">Dragi=C5=A1a Duri=C4=87class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: = >normal; font-weight: normal; letter-spacing: normal; line-height: = >normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = >text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = >Helvetica; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; orphans: 2; = >text-align: -webkit-auto; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">

= >

>
>
= > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4-- > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename=signature.asc >Content-Type: application/pgp-signature; > name=signature.asc >Content-Description: Message signed with OpenPGP using GPGMail > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > >iQEcBAEBAgAGBQJRYGwFAAoJEJtljYXUJo8xGvgH/0MAKizqVsumCaf25qcldgcH >PPBGWW5VPRmTEDU2sgRD+1HdkiXwW9Bq5l6Ywv6uIdbZF5SYv64+EAwb9ZCBwIDo >2SxOKZmr0Z4ECl5Jyn6MgZxIOq4sVdHhQ+F5k/1o7C0v7x582A0Td8QnvijoQdRs >LQqQW9ZNYlLDf57dlpCm5+baXem8KO1PNo7Z4If2ceTEaqIb++Ax/Nc8wzEqN1uD >br4GfPKzNmJgQ6RlHbqdoesM4HmbdF2nxMSkVdA8Ydgi5EQH4zBEKFfOsp1uzRjC >VtUkeBwhQyLWNQaaJlR4rzbMDLJprdIyrs9WYQKMALGoYZQiDecy/oH6s8Awgi0= >=tvjq >-----END PGP SIGNATURE----- > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF-- From jay.krell at cornell.edu Sat Apr 6 23:59:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Apr 2013 21:59:26 +0000 Subject: [M3devel] alternate implementation of opaque types? Message-ID: Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? We do suffer from the "fragile base type" problem either way, right? Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. With my proposed change, you can recompile less actually. Though we probably wouldn't bother. As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 01:23:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Apr 2013 23:23:38 +0000 Subject: [M3devel] cm3 should process -D on command line earlier? Message-ID: > cm3 should process -D on command line earlier? I want to be able to say in the config file: if defined("cm3_verbose") M3_FRONT_FLAGS += ["-v"] end if defined("cm3_verbose_version_stamps") M3_FRONT_FLAGS += ["-vsdebug"] end this doesn't quite work because cm3 processes the -D on the command line fairly late -- after it reads "the config file" and before it reads "the m3makefile". (Each of which can and often does include additional files.) I'm working on this change. Alternative a specific flag to cm3 for each frontend flag might be good. I guess verbose is actually already handled. Shall I just "pretend" they are the same? Add frontend flags to cm3 and have cm3 pass them on? i.e. specifically -vsdebug? see /cm3/m3-sys/m3front/src/misc/Host.m3 for possible frontend flags Hm..the thing is, these are mostly meant to be pretty obscure. Often-but-not-always target-specific, set by the config file, and not meant to be user-editable. For example the C backend and NT386 backend have requirements around -inline_nested_procs vs. -unfold_nested_procs. Though really the C backend could easily be made to work either way, esp. at this point that it is many-pass. Reasonable? (I'm specifically wanting -vsdebug to track down what types the C backend is seemingly uninformed about...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 07:56:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 05:56:29 +0000 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? Message-ID: In the C backend, I would like to share code for records and objects. As I understand, objects are always pointers. In my framework, I map typeids to type information. For this to work, given an object, I need to declare both a record and a pointer to it. I need two typeids for that. I'm in the position where I need to compute a typeid. Is that feasible? I have two choices if I can't do that: 1) map from strings instead, where the strings tend to be a string form of a typeid, but where I can make up other forms; quite an inefficiency 1b) have two maps maybe 2) build a flag into my record data that indicates "record or object" #1 is easy but I'm leary of the inefficiency. I'll probably try #2 instead then. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 08:26:46 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 06:26:46 +0000 Subject: [M3devel] m3front/src/types/TypeRep.i3 NO_UID Message-ID: m3front/src/types/TypeRep.i3 NO_UID = -1 is it really guaranteed that a typeid won't end up being -1? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Apr 7 10:03:46 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Apr 2013 10:03:46 +0200 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: Message-ID: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> I second this. I never had problems with these instances of "over-compilation". Why bother, and why introduce possible problems down the road by fixing what is not broken? -- Dragi?a Duri? dragisha at m3w.org On Apr 6, 2013, at 11:59 PM, Jay K wrote: > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 7 13:09:51 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Apr 2013 21:09:51 +1000 Subject: [M3devel] m3front/src/types/TypeRep.i3 NO_UID In-Reply-To: References: Message-ID: Yes. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Apr 7, 2013, at 4:26 PM, Jay K wrote: > m3front/src/types/TypeRep.i3 NO_UID = -1 > is it really guaranteed that a typeid won't end up being -1? > > > Thanks, > - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 7 13:10:03 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Apr 2013 21:10:03 +1000 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> References: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> Message-ID: <5618C4A4-E9AB-460F-BAF6-D59B0623DDA4@cs.purdue.edu> There can be multiple levels of opacity. So I don?t see how you would do this. On Apr 7, 2013, at 6:03 PM, Dragi?a Duri? wrote: > I second this. I never had problems with these instances of "over-compilation". Why bother, and why introduce possible problems down the road by fixing what is not broken? > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 6, 2013, at 11:59 PM, Jay K wrote: > >> With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 7 17:48:57 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 10:48:57 -0500 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: Message-ID: <51619569.4070202@lcwb.coop> On 04/06/2013 04:59 PM, Jay K wrote: > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > This is neither an implementation nor a language design question, but a programmer's option. The language allows private things before or after public, or more complicated combinations, e.g., private, public, private. In fact, arbitrary combinations are possible, although how to put them together gets tricky and requires a lot of separate compilations. Here is a public-private-public example that is, I think, believable: INTERFACE Stack ; TYPE T <: Public ; TYPE Public = OBJECT METHODS push ( I : INTEGER ) ... END (* Public *) ; END Stack . (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) Later, somebody else wants to add: INTERFACE StackWithStats ; IMPORT Stack ; TYPE T = Stack . T OBJECT PushCt : CARDINAL := 0 ... OVERRIDES push := Push ... END (* T *) ; PROCEDURE Push ( s : T ; I : INTEGER ) ; END StackWithStats . MODULE StackWithStats ; PROCEDURE Push ( s : T ; I : INTEGER ) = BEGIN INC ( s . PushCt ) ; Stack . T . push ( s , I ) END Push ... ; BEGIN END StackWithStats . > > We do suffer from the "fragile base type" problem either way, right? > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > - Jay From rodney_bates at lcwb.coop Sun Apr 7 18:02:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 11:02:51 -0500 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: References: Message-ID: <516198AB.5040509@lcwb.coop> On 04/07/2013 12:56 AM, Jay K wrote: > In the C backend, I would like to share code for records and objects. > > > As I understand, objects are always pointers. Yes. > > > In my framework, I map typeids to type information. > > > For this to work, given an object, I need to declare both a record > and a pointer to it. I need two typeids for that. > > > I'm in the position where I need to compute a typeid. > Is that feasible? > > > > I have two choices if I can't do that: > > > 1) map from strings instead, where the strings tend to be > a string form of a typeid, but where I can make up other forms; > quite an inefficiency > > > 1b) have two maps maybe > > > > 2) build a flag into my record data that indicates "record or object" FWIW, I believe it is true that every way of using an object type in Modula-3 implicitly and uniquely identifies whether it works on the pointer or the heap object. For example, := and = mean the pointer, while any use of . implies dereferencing. There is no whole-object assignment or whole-object comparison, as there are for REF RECORD (which has two types). Maybe this distinction is lost in the lowering that happens by the time M3C gets it, or later. > > > #1 is easy but I'm leary of the inefficiency. > I'll probably try #2 instead then. > > > > - Jay > > From rodney_bates at lcwb.coop Sun Apr 7 18:21:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 11:21:40 -0500 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: References: Message-ID: <51619D14.6070903@lcwb.coop> On 04/06/2013 01:40 PM, Dragi?a Duri? wrote: > Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? > > new source -> compiling XLModule.m3 > "../src/XLModule.m3", line 181: NARROW: types must be assignable > "../src/XLModule.m3", line 239: incompatible types (x) > From 2.2.10: NULL <: REF T <: REFANY and similarly, any object type <: ROOT <: REFANY but while NULL <: PROCEDURE... NOT PROCEDURE... <: REFANY nor PROCEDURE... <: ADDRESS Which is why you can't assign a procedure value to a pointer of any kind, nor can you narrow a pointer back to a procedure. Changing the language to allow this would, I think, entail significant implementation complexity. Do you want all of the procedure values in the sequence to be the same procedure type? If so, you should be able to just instantiate Sequence using an interface containing a T that is this procedure type. No runtime NARROW overhead, and more static checking. Otherwise, Mika's wrapping example should be extensible by having a different wrapper type around each needed procedure type. Then they could be mixed and matched in a single sequence. > Second one is RefSeq.T.addhi(procedureType) > > TIA, > dd > -- > Dragi?a Duri? > dragisha at m3w.org > > > From dragisha at m3w.org Sun Apr 7 18:47:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Apr 2013 18:47:15 +0200 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: <51619D14.6070903@lcwb.coop> References: <51619D14.6070903@lcwb.coop> Message-ID: <4A99AADA-503C-4BA9-9FAA-9133796EA851@m3w.org> Mika's idea is exactly what I needed. I was cleaning some old code and ARRAY's of fixed size "emulating" collections are one my favourite targets :). More than enough, and more than powerful enough, this mechanism is. -- Dragi?a Duri? dragisha at m3w.org On Apr 7, 2013, at 6:21 PM, Rodney M. Bates wrote: > Do you want all of the procedure values in the sequence to be the same > procedure type? If so, you should be able to just instantiate Sequence > using an interface containing a T that is this procedure type. No > runtime NARROW overhead, and more static checking. > > Otherwise, Mika's wrapping example should be extensible by having a different > wrapper type around each needed procedure type. Then they could be mixed and > matched in a single sequence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 7 19:23:59 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 07 Apr 2013 10:23:59 -0700 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: <51619D14.6070903@lcwb.coop> References: <51619D14.6070903@lcwb.coop> Message-ID: <20130407172359.7DD2E1A207D@async.async.caltech.edu> I should add that m3tk could be used to generate such procedure type wrappers automatically. It's one of the things I never got around to in my Scheme system (since you can usually just use OBJECTs anyhow, at least if you control the source code), but it shouldn't be too difficult... Mika "Rodney M. Bates" writes: > > >On 04/06/2013 01:40 PM, Dragi??a Duri?? wrote: >> Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? >> >> new source -> compiling XLModule.m3 >> "../src/XLModule.m3", line 181: NARROW: types must be assignable >> "../src/XLModule.m3", line 239: incompatible types (x) >> > > From 2.2.10: > >NULL <: REF T <: REFANY >and similarly, any object type <: ROOT <: REFANY > >but while NULL <: PROCEDURE... >NOT PROCEDURE... <: REFANY nor PROCEDURE... <: ADDRESS > >Which is why you can't assign a procedure value to a pointer of any kind, nor >can you narrow a pointer back to a procedure. Changing the language to allow >this would, I think, entail significant implementation complexity. > >Do you want all of the procedure values in the sequence to be the same >procedure type? If so, you should be able to just instantiate Sequence >using an interface containing a T that is this procedure type. No >runtime NARROW overhead, and more static checking. > >Otherwise, Mika's wrapping example should be extensible by having a different >wrapper type around each needed procedure type. Then they could be mixed and >matched in a single sequence. > >> Second one is RefSeq.T.addhi(procedureType) >> >> TIA, >> dd >> -- >> Dragi??a Duri?? >> dragisha at m3w.org >> >> >> From hendrik at topoi.pooq.com Sun Apr 7 20:37:46 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Apr 2013 14:37:46 -0400 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: <516198AB.5040509@lcwb.coop> References: <516198AB.5040509@lcwb.coop> Message-ID: <20130407183746.GB24973@topoi.pooq.com> On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote: > > > On 04/07/2013 12:56 AM, Jay K wrote: > >In the C backend, I would like to share code for records and objects. > > > > > >As I understand, objects are always pointers. > > Yes. > > > > > > >In my framework, I map typeids to type information. > > > > > >For this to work, given an object, I need to declare both a record > >and a pointer to it. I need two typeids for that. > > > > > >I'm in the position where I need to compute a typeid. > >Is that feasible? > > > > > > > >I have two choices if I can't do that: > > > > > > 1) map from strings instead, where the strings tend to be > > a string form of a typeid, but where I can make up other forms; > > quite an inefficiency > > > > > > 1b) have two maps maybe > > > > > > > > 2) build a flag into my record data that indicates "record or object" > > FWIW, I believe it is true that every way of using an object type in Modula-3 > implicitly and uniquely identifies whether it works on the pointer or the > heap object. For example, := and = mean the pointer, while any use of . implies > dereferencing. There is no whole-object assignment or whole-object comparison, > as there are for REF RECORD (which has two types). > > Maybe this distinction is lost in the lowering that happens by the time M3C gets it, > or later. I this matter Modula 3 is very different from C++, which idenntifies classes wiith structure types. It even treats struct and class as equivalent keywords. That was a big mistake in C++, and results in pathological behavior when assigning class values instead of class pointers. -- hendrik k From jay.krell at cornell.edu Sun Apr 7 21:07:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 19:07:15 +0000 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: <51619569.4070202@lcwb.coop> References: , <51619569.4070202@lcwb.coop> Message-ID: My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > The language allows private things before or after public, or more complicated combinations, I didn't realize. - Jay > Date: Sun, 7 Apr 2013 10:48:57 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > This is neither an implementation nor a language design question, but a programmer's option. > The language allows private things before or after public, or more complicated combinations, > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > to put them together gets tricky and requires a lot of separate compilations. > > Here is a public-private-public example that is, I think, believable: > > INTERFACE Stack > ; TYPE T <: Public > ; TYPE Public = OBJECT METHODS > push ( I : INTEGER ) > ... > END (* Public *) > ; END Stack . > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > Later, somebody else wants to add: > > INTERFACE StackWithStats > ; IMPORT Stack > ; TYPE T = Stack . T OBJECT > PushCt : CARDINAL := 0 > ... > OVERRIDES > push := Push > ... > END (* T *) > ; PROCEDURE Push ( s : T ; I : INTEGER ) > ; END StackWithStats . > > MODULE StackWithStats > ; PROCEDURE Push ( s : T ; I : INTEGER ) > = BEGIN > INC ( s . PushCt ) > ; Stack . T . push ( s , I ) > END Push > ... > ; BEGIN END StackWithStats . > > > > > We do suffer from the "fragile base type" problem either way, right? > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 21:16:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 19:16:41 +0000 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: <20130407183746.GB24973@topoi.pooq.com> References: , <516198AB.5040509@lcwb.coop>, <20130407183746.GB24973@topoi.pooq.com> Message-ID: I figured out a way that probably works. I use -1 for the typeid of the made up record, and hope that I don't need it. What C++ does makes a lot of sense actually. What you are missing is that "classes" or "types" have different use-cases. More than 2. Stroustrup identifies a few. Off the top of my head, though: 1) value types like std::string Here the value semantics are what you want. This also includes container classes like std::vector, std::queue, etc., that you don't often want to assign, but when you do, they offer a good way to do it. 2) typical "object oriented stuff" like "Window" with virtual functions that get overridden 3) "object oriented stuff" w/ plugins like how Modula-3 Rd/Wr work and how C++ iostreams work -- you plugin a "buffer". You always call "toplevel" non-overridden functions that selectively call more derived overrides. The toplevel provides a "framework" and common code is lifted out of the derived types, leaving them only to implement "what varies". I think actually in general #2 is overrused and #3 is kind of better. #1 is different and appropriately often used. 4) Sometimes just for scoping globals, i.e. "singleton" / "manager" classes. The way you enforce stuff is that types that aren't meant to be assigned should have abstract functions, so you can't instantiate them directly. And then, also, you wrap up #2/#3 in #1 -- std::unique_ptr / std::shared_ptr and such. Modula-3 favors only #2 or #3. Many languages don't have good support for #1 really. You know -- Modula-3 TEXT and java String get special treatment by the compiler and w/o compiler support, nobody can implement anything quite like them, whereas C++ std::string is implemented with powers available to anyone. Anyway, I think I solved my problem. Aside from opaque types always being "ADDRESS", I have good typeinfo in the C backend now. Also exluding global variables, which remain awful. Now to start using these types for locals/parameters... - Jay > Date: Sun, 7 Apr 2013 14:37:46 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] computing a typeid in backend for a pointer to a declared type?? > > On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote: > > > > > > On 04/07/2013 12:56 AM, Jay K wrote: > > >In the C backend, I would like to share code for records and objects. > > > > > > > > >As I understand, objects are always pointers. > > > > Yes. > > > > > > > > > > >In my framework, I map typeids to type information. > > > > > > > > >For this to work, given an object, I need to declare both a record > > >and a pointer to it. I need two typeids for that. > > > > > > > > >I'm in the position where I need to compute a typeid. > > >Is that feasible? > > > > > > > > > > > >I have two choices if I can't do that: > > > > > > > > > 1) map from strings instead, where the strings tend to be > > > a string form of a typeid, but where I can make up other forms; > > > quite an inefficiency > > > > > > > > > 1b) have two maps maybe > > > > > > > > > > > > 2) build a flag into my record data that indicates "record or object" > > > > FWIW, I believe it is true that every way of using an object type in Modula-3 > > implicitly and uniquely identifies whether it works on the pointer or the > > heap object. For example, := and = mean the pointer, while any use of . implies > > dereferencing. There is no whole-object assignment or whole-object comparison, > > as there are for REF RECORD (which has two types). > > > > Maybe this distinction is lost in the lowering that happens by the time M3C gets it, > > or later. > > I this matter Modula 3 is very different from C++, which idenntifies > classes wiith structure types. It even treats struct and class as > equivalent keywords. That was a big mistake in C++, and > results in pathological behavior when assigning class > values instead of class pointers. > > -- hendrik > k -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Mon Apr 8 12:37:46 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Mon, 8 Apr 2013 12:37:46 +0200 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: , <51619569.4070202@lcwb.coop> Message-ID: If M3 would merge interfaces and modules, like Oberon and golang have done, with the addition of selective export (hidden, readonly, public) of record/object fields and mixins (aka called "interfaces" in Java and C#), it wouldn't need the extra complications of opaque types at all. From: Jay K Sent: Sunday, April 07, 2013 9:07 PM To: Rodney M. Bates ; m3devel Subject: Re: [M3devel] alternate implementation of opaque types? My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > The language allows private things before or after public, or more complicated combinations, I didn't realize. - Jay > Date: Sun, 7 Apr 2013 10:48:57 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > This is neither an implementation nor a language design question, but a programmer's option. > The language allows private things before or after public, or more complicated combinations, > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > to put them together gets tricky and requires a lot of separate compilations. > > Here is a public-private-public example that is, I think, believable: > > INTERFACE Stack > ; TYPE T <: Public > ; TYPE Public = OBJECT METHODS > push ( I : INTEGER ) > ... > END (* Public *) > ; END Stack . > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > Later, somebody else wants to add: > > INTERFACE StackWithStats > ; IMPORT Stack > ; TYPE T = Stack . T OBJECT > PushCt : CARDINAL := 0 > ... > OVERRIDES > push := Push > ... > END (* T *) > ; PROCEDURE Push ( s : T ; I : INTEGER ) > ; END StackWithStats . > > MODULE StackWithStats > ; PROCEDURE Push ( s : T ; I : INTEGER ) > = BEGIN > INC ( s . PushCt ) > ; Stack . T . push ( s , I ) > END Push > ... > ; BEGIN END StackWithStats . > > > > > We do suffer from the "fragile base type" problem either way, right? > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 8 18:08:08 2013 From: jay.krell at cornell.edu (Jay) Date: Mon, 8 Apr 2013 09:08:08 -0700 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: <51619569.4070202@lcwb.coop> Message-ID: I agree COM/Java/C# interfaces are very good for structuring large systems, maintaining opacity, and are reasonably simple and efficient. They preclude direct access to public data, for better and worse. They are achievable in Modula-3, like in C, tediously and you invent your own idiom (a separate object, with back pointer to the "real" one, and small functions to forward to it.) I don't know what Oberon/golang do here. - Jay On Apr 8, 2013, at 3:37 AM, Dirk Muysers wrote: > If M3 would merge interfaces and modules, like Oberon and golang > have done, with the addition of selective export (hidden, readonly, public) > of record/object fields and mixins (aka called "interfaces" in Java and C#), > it wouldn't need the extra complications of opaque types at all. > > From: Jay K > Sent: Sunday, April 07, 2013 9:07 PM > To: Rodney M. Bates ; m3devel > Subject: Re: [M3devel] alternate implementation of opaque types? > > My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. > > > If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > > > > The language allows private things before or after public, or more complicated combinations, > > > I didn't realize. > > > - Jay > > > > Date: Sun, 7 Apr 2013 10:48:57 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > > > > This is neither an implementation nor a language design question, but a programmer's option. > > The language allows private things before or after public, or more complicated combinations, > > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > > to put them together gets tricky and requires a lot of separate compilations. > > > > Here is a public-private-public example that is, I think, believable: > > > > INTERFACE Stack > > ; TYPE T <: Public > > ; TYPE Public = OBJECT METHODS > > push ( I : INTEGER ) > > ... > > END (* Public *) > > ; END Stack . > > > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > > > Later, somebody else wants to add: > > > > INTERFACE StackWithStats > > ; IMPORT Stack > > ; TYPE T = Stack . T OBJECT > > PushCt : CARDINAL := 0 > > ... > > OVERRIDES > > push := Push > > ... > > END (* T *) > > ; PROCEDURE Push ( s : T ; I : INTEGER ) > > ; END StackWithStats . > > > > MODULE StackWithStats > > ; PROCEDURE Push ( s : T ; I : INTEGER ) > > = BEGIN > > INC ( s . PushCt ) > > ; Stack . T . push ( s , I ) > > END Push > > ... > > ; BEGIN END StackWithStats . > > > > > > > > We do suffer from the "fragile base type" problem either way, right? > > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 8 21:06:24 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Apr 2013 19:06:24 +0000 Subject: [M3devel] dbxout.c commit In-Reply-To: <20130408183918.555525DEA9D@birch.elegosoft.com> References: <20130408183918.555525DEA9D@birch.elegosoft.com> Message-ID: Note that this file is pretty dead. see cm3/m3-sys/m3cc/gcc-4.5/gcc/dbxout.c cm3/m3-sys/m3cc/gcc-4.6/gcc/dbxout.c cm3/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c cm3/m3-sys/m3cc/src/m3makefile As I recall: 4.5 was in use a while, maybe in the previous release? 4.6 I don't think was in use much, and contains the heavier handed optimizer removal by me most systems are using 4.7, but it hasn't been for long The "unversioned" directory is 4.3. We never imported 4.4. - Jay > Date: Mon, 8 Apr 2013 20:39:18 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/04/08 20:39:18 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c > > Log message: > Some end-of-function comments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 9 17:52:04 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 09 Apr 2013 10:52:04 -0500 Subject: [M3devel] dbxout.c commit In-Reply-To: References: <20130408183918.555525DEA9D@birch.elegosoft.com> Message-ID: <51643924.603@lcwb.coop> Yeah, I've realized for a while I have more work than adding trivial comments, for these three new gcc backends. On 04/08/2013 02:06 PM, Jay K wrote: > Note that this file is pretty dead. > > see > cm3/m3-sys/m3cc/gcc-4.5/gcc/dbxout.c > cm3/m3-sys/m3cc/gcc-4.6/gcc/dbxout.c > cm3/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c > cm3/m3-sys/m3cc/src/m3makefile > > As I recall: > 4.5 was in use a while, maybe in the previous release? > 4.6 I don't think was in use much, and contains the heavier handed optimizer removal by me > most systems are using 4.7, but it hasn't been for long > The "unversioned" directory is 4.3. > We never imported 4.4. > > > - Jay > > > Date: Mon, 8 Apr 2013 20:39:18 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/04/08 20:39:18 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c > > > > Log message: > > Some end-of-function comments. > > From jay.krell at cornell.edu Wed Apr 10 04:12:52 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Apr 2013 02:12:52 +0000 Subject: [M3devel] typenames vs. typeids in M3CG? Message-ID: Given something like: TYPE A = RECORD ... END; (* typeid 123456 *) TYPE B = A; VAR a:A; VAR b:B; ideally the generated code looks like: struct T123456; typedef struct T123456 T123456; struct T123456 { ... }; typedef T123456 A; typedef T123456 B; A a; B b; Currently I produce: T123456 a; T123456 b; it is easy to make the first or better yet last typename for any given typeid win, giving us: B a; B b; However actually producing the ideal/idiomatic: A a; B b; I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. Reasonable? The problem seems worst for records. But it applies to enums, subranges, opaque types. Actual source is full of typenames. M3CG is full of typeids. TYPE Color = {Red, Blue, Green}; The thing to the right is anonymous type with a typeid (structural hash). TYPE Color2 = {Red, Blue, Green}; VAR Color:c; VAR Color2:c2; In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ Color c; Color2 c2; However, again, without frontend help we are faced with probably: T1234 c; T1234 c2; or perhaps Color c; Color2 c2; Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. Similarly for opaque types, currently I have: typdef char* ADDRESS; TYPE A <: whatever; TYPE B <: whatever; typedef ADDRESS T1234; (* typeid for opaque type *) typedef ADDRESS T123478; (* typeid for opaque type *) T1234 a; T123478 b; This is not particularly readable. It can go either way: ADDRESS a; ADDRESS b; Or ideally more like: A* a; B* b; or A a; B b; Opaque types are a larger problem, at least in my head. I'd like to have pointers to structs, but I don't yet know how to make that work. Either the public part or the entire thing. If the information is available. The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) If you have used stock gdb or debugged the NT386 target, you should realize the problem. I believe the frontend should be passing typenames along with typeids for locals/parameters. I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. Advise? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 10 05:43:26 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Apr 2013 13:43:26 +1000 Subject: [M3devel] typenames vs. typeids in M3CG? In-Reply-To: References: Message-ID: <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> I actually prefer the declarations T123456 a; T123456 b; Type names mean nothing in Modula-3?s structural type system. On Apr 10, 2013, at 12:12 PM, Jay K wrote: > Given something like: > > > TYPE A = RECORD ... END; (* typeid 123456 *) > TYPE B = A; > > > VAR a:A; > VAR b:B; > > > > ideally the generated code looks like: > > > struct T123456; typedef struct T123456 T123456; > struct T123456 { ... }; > > > typedef T123456 A; > typedef T123456 B; > A a; > B b; > > Currently I produce: > T123456 a; > T123456 b; > > it is easy to make the first or better yet last typename for any given typeid win, giving us: > B a; > B b; > > However actually producing the ideal/idiomatic: > A a; > B b; > > I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. > Reasonable? > > > The problem seems worst for records. > But it applies to enums, subranges, opaque types. > > > Actual source is full of typenames. M3CG is full of typeids. > > > TYPE Color = {Red, Blue, Green}; > > > The thing to the right is anonymous type with a typeid (structural hash). > > > TYPE Color2 = {Red, Blue, Green}; > > VAR Color:c; > VAR Color2:c2; > > > In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: > > typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ > > > Color c; > Color2 c2; > > > However, again, without frontend help we are faced with probably: > T1234 c; > T1234 c2; > > or perhaps > Color c; > Color2 c2; > > > Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. > That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. > > > Similarly for opaque types, currently I have: > > > typdef char* ADDRESS; > TYPE A <: whatever; > TYPE B <: whatever; > > > typedef ADDRESS T1234; (* typeid for opaque type *) > typedef ADDRESS T123478; (* typeid for opaque type *) > > > T1234 a; > T123478 b; > > > This is not particularly readable. > It can go either way: > ADDRESS a; > ADDRESS b; > > > Or ideally more like: > A* a; > B* b; > > > or > A a; > B b; > > > Opaque types are a larger problem, at least in my head. > I'd like to have pointers to structs, but I don't yet know how to make that work. > Either the public part or the entire thing. If the information is available. > > > The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. > (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) > > > If you have used stock gdb or debugged the NT386 target, you should realize the problem. > > > I believe the frontend should be passing typenames along with typeids for locals/parameters. > I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. > Advise? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 10 17:14:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Apr 2013 15:14:27 +0000 Subject: [M3devel] typenames vs. typeids in M3CG? In-Reply-To: <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> References: , <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> Message-ID: In the debugger and, I somewhat lied, for the C to somewhat mimic the Modula-3, I'd definitely prefer "A" and "B". C++ programmers wrestle with this, but it is widely agreed to be a "quality bug" (correct but not ideal) and ought to be fixed. If I say: std::string a; and hover over it in a debugger, I see something ridiculous std::basic_string<...something really long>. The (Microsoft, at least) compiler was fixed to issue warnings in terms of "used types" instead of "alias bases", but the debuginfo was not. Enums are likely to end up like: enum T1234 { T1234_Red, T1234_Blue, T1234_Green }; anything given just one typename I have a chance of "fixing" well. But in the face of multiple typenames, an arbitrary one will win. I can go back and replace the text T1234 with "Color" or or "Color_" whatnot..even in the enum members. - Jay From: hosking at cs.purdue.edu Date: Wed, 10 Apr 2013 13:43:26 +1000 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] typenames vs. typeids in M3CG? I actually prefer the declarations T123456 a;T123456 b; Type names mean nothing in Modula-3?s structural type system. On Apr 10, 2013, at 12:12 PM, Jay K wrote:Given something like: TYPE A = RECORD ... END; (* typeid 123456 *) TYPE B = A; VAR a:A; VAR b:B; ideally the generated code looks like: struct T123456; typedef struct T123456 T123456; struct T123456 { ... }; typedef T123456 A; typedef T123456 B; A a; B b; Currently I produce: T123456 a; T123456 b; it is easy to make the first or better yet last typename for any given typeid win, giving us: B a; B b; However actually producing the ideal/idiomatic: A a; B b; I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. Reasonable? The problem seems worst for records. But it applies to enums, subranges, opaque types. Actual source is full of typenames. M3CG is full of typeids. TYPE Color = {Red, Blue, Green}; The thing to the right is anonymous type with a typeid (structural hash). TYPE Color2 = {Red, Blue, Green}; VAR Color:c; VAR Color2:c2; In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ Color c; Color2 c2; However, again, without frontend help we are faced with probably: T1234 c; T1234 c2; or perhaps Color c; Color2 c2; Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. Similarly for opaque types, currently I have: typdef char* ADDRESS; TYPE A <: whatever; TYPE B <: whatever; typedef ADDRESS T1234; (* typeid for opaque type *) typedef ADDRESS T123478; (* typeid for opaque type *) T1234 a; T123478 b; This is not particularly readable. It can go either way: ADDRESS a; ADDRESS b; Or ideally more like: A* a; B* b; or A a; B b; Opaque types are a larger problem, at least in my head. I'd like to have pointers to structs, but I don't yet know how to make that work. Either the public part or the entire thing. If the information is available. The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) If you have used stock gdb or debugged the NT386 target, you should realize the problem. I believe the frontend should be passing typenames along with typeids for locals/parameters. I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. Advise? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 07:14:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 05:14:10 +0000 Subject: [M3devel] 32bit negative base 16 constants? Message-ID: I have some 32bit constants. e.g.: CONST UID_WORD = 16_97E237E2; but this isn't right. On a 64bit system, that is a 64bit integer with a "large" positive value, instead of the intended 32bit negative value. Is there an ideal (i.e. CONST) way to do this? Portably to 64bit systems? I have found two unsatisfactory choices: 1) use decimal: #include int main() { printf("%X %d\n", 0x97E237E2); return 0; } cc 1.c ./a.out 97E237E2 -1881139893 CONST UID_WORD = (* 16_97E237E2 *) -1881139893; 2) change it to VAR and a runtime conversion: PROCEDURE SignExtend(a, b: INTEGER): INTEGER = BEGIN b := Word.LeftShift(-1, b - 1); IF Word.And(a, b) # 0 THEN a := Word.Or(a, b); END; RETURN a; END SignExtend; PROCEDURE SignExtend32(a: INTEGER): INT32 = BEGIN RETURN SignExtend(a, 32); END SignExtend32; CONST IntegerToTypeid = SignExtend32; VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) This gives a warning: CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) and then at runtime gives an error assigning it to an INT32. any other ways? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 11 08:03:02 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Apr 2013 16:03:02 +1000 Subject: [M3devel] 32bit negative base 16 constants? In-Reply-To: References: Message-ID: <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> Actually, writing that you get what you expressed: If an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation uses the convention of the Word interface. Word.T is unsigned, so you only get the 32 bits you asked for. If you want a signed value then you need to express the sign explicitly starting from a constant, just as you have done with: > CONST UID_WORD = (* 16_97E237E2 *) -1881139893; On Apr 11, 2013, at 3:14 PM, Jay K wrote: > > I have some 32bit constants. > > e.g.: > > CONST UID_WORD = 16_97E237E2; > > but this isn't right. > On a 64bit system, that is a 64bit integer > with a "large" positive value, instead of > the intended 32bit negative value. > > Is there an ideal (i.e. CONST) way to do this? > Portably to 64bit systems? > > I have found two unsatisfactory choices: > > 1) use decimal: > > #include > int main() > { > printf("%X %d\n", 0x97E237E2); > return 0; > } > > > cc 1.c > ./a.out > 97E237E2 -1881139893 > > CONST UID_WORD = (* 16_97E237E2 *) -1881139893; > > > 2) change it to VAR and a runtime conversion: > > > PROCEDURE SignExtend(a, b: INTEGER): INTEGER = > BEGIN > b := Word.LeftShift(-1, b - 1); > IF Word.And(a, b) # 0 THEN > a := Word.Or(a, b); > END; > RETURN a; > END SignExtend; > > PROCEDURE SignExtend32(a: INTEGER): INT32 = > BEGIN > RETURN SignExtend(a, 32); > END SignExtend32; > > CONST IntegerToTypeid = SignExtend32; > > > VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) > > This gives a warning: > > CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) > > and then at runtime gives an error assigning it to an INT32. > > > any other ways? > > > Thanks, > - Jay > > Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 08:17:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 06:17:51 +0000 Subject: [M3devel] 32bit negative base 16 constants? In-Reply-To: <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> References: , <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> Message-ID: I want a 32bit signed value expressed in base 16 where e.g. 16_FFFFFFFF is equivalent to -1. - Jay From: hosking at cs.purdue.edu Date: Thu, 11 Apr 2013 16:03:02 +1000 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] 32bit negative base 16 constants? Actually, writing that you get what you expressed: If an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation uses the convention of the Word interface. Word.T is unsigned, so you only get the 32 bits you asked for. If you want a signed value then you need to express the sign explicitly starting from a constant, just as you have done with: CONST UID_WORD = (* 16_97E237E2 *) -1881139893; On Apr 11, 2013, at 3:14 PM, Jay K wrote: I have some 32bit constants. e.g.: CONST UID_WORD = 16_97E237E2; but this isn't right. On a 64bit system, that is a 64bit integer with a "large" positive value, instead of the intended 32bit negative value. Is there an ideal (i.e. CONST) way to do this? Portably to 64bit systems? I have found two unsatisfactory choices: 1) use decimal: #include int main() { printf("%X %d\n", 0x97E237E2); return 0; } cc 1.c ./a.out 97E237E2 -1881139893 CONST UID_WORD = (* 16_97E237E2 *) -1881139893; 2) change it to VAR and a runtime conversion: PROCEDURE SignExtend(a, b: INTEGER): INTEGER = BEGIN b := Word.LeftShift(-1, b - 1); IF Word.And(a, b) # 0 THEN a := Word.Or(a, b); END; RETURN a; END SignExtend; PROCEDURE SignExtend32(a: INTEGER): INT32 = BEGIN RETURN SignExtend(a, 32); END SignExtend32; CONST IntegerToTypeid = SignExtend32; VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) This gives a warning: CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) and then at runtime gives an error assigning it to an INT32. any other ways? Thanks, - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 10:28:22 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 08:28:22 +0000 Subject: [M3devel] temporary records lack typeids Message-ID: It'd be nice if temporary records had typeids. Specifically, it'd be nice if closures, instead of being "3 word CGType.Struct" where more like declare_record 3 fields typeidxxx declare_field integer marker declare_field address function_pointer declare_field address static_link declare_typename closure = typeidxxx Then: 1) they'd be viewable somewhat in a debugger note that the static_link is up to the backend to define. It is also a pointer to a struct, but the frontend doesn't know that 2) I could soon dispense with my mechanism for declaring structs with size but not particular fields. i.e. #define M3STRUCT(n) m3struct_##n##_t #define M3STRUCT1(n) typedef struct { volatile UINT8 a[n]; } M3STRUCT(n); #define M3STRUCT2(n) typedef struct { volatile UINT16 a[(n)/2]; } M3STRUCT(n); #define M3STRUCT4(n) typedef struct { volatile UINT32 a[(n)/4]; } M3STRUCT(n); #define M3STRUCT8(n) typedef struct { volatile UINT64 a[(n)/8]; } M3STRUCT(n); ... M3STRUCT8(8) M3STRUCT8(24) ... M3STRUCT(24) L_32_L_33 = { 0 }; all structs were using this, but now likely only closures are..er...what is that 8 byte struct? That is also something I'll remove soon, unfinished work making uplevel structs strongly typed. Maybe a long standing bug in the C backend also. I'll know soon.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 20:57:53 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 18:57:53 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend Message-ID: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 11 23:12:42 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Apr 2013 07:12:42 +1000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: References: Message-ID: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: > The C/C++ works, for a while now, and is improving nicely (wrt debuggability). > > > Here are some current problems/dilemnas. > > > --- getting pointer parameters correctly typed esp. on passing side --- > > > Up until now, any pointer parameter to a function has been typed as char*. > > > (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do > math on them; however given that char* is usually wrong, void* actually debugs better, > showing nothing instead of garbage. gcc does allow math on void* but it > is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; > I should probably use void* with gcc and wherever the extension is supported...autoconf...) > Anyway.. > Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). > This works but is bad for debugging (again: void* is better than char*, but both are bad) > I've been working on this. > > > The interface to the backend is > pop_param(cgtype) > pop_struct(typeid, size) > > > non-struct readonly and var parameters are just: > pop_param(cgtype.addr) > > > It would be nice if the frontend also passed a typeid here, > and either using the typeid from a "declare_indirect" or "declare_pointer" > or had separate booleans/flags for readonly/var. > > > How about: > TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); > > > might as well merge this with pop_struct, no further change required probably. > > Or, at worst, another mode: > TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); > > > or less abstract: > TYPE ParameterMode = {Value, Pointer, StructByValue}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); > > > or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, > I like it: > > (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant > Backends without type checking can ignore typeid. e.g. NTx86.m3. > bitSize is definitely redundant, but helps typeid-ignoring backends > that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. > cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) > cgtype will be CGType.Struct for struct-by-value (size in bitSize) > typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) > typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); > > > Ideally all backends would track typeids and it'd suffice to say: > (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) > typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) > PROCEDURE pop_param(typeid: TypeUID); > > > but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. > (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), > and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) > > > I haven't looked to see if this information (typeid/size for pop_param) > is readily available in the frontend. I will do that soon. > > > I have a few potential workarounds: > cast to void* > This appears to be working, with limited testing (my new test case, p254) > Big drawback here is the code is no longer valid C++, only C. > This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. > The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ > doesn't allow conversion from void* to other pointer types without a cast. > > > Introspect on the function pointer type and cast appropriately, or even not at all. > This should provide the ideal output and is probably viable. I'll look into it later. > > > Cast the function to (*)(...) for C++ or (*)() for C. > This is kind of gross. Hopefully it is not a deoptimization, but it might be. > I already do such casting for indirect function calls, for reasons to do with the static link. > I'm going to try this next. > > > --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- > > Now a minor dilemna, not a problem. > > > Up until recently, I didn't have much type information flowing through the C backend. > Or specifically I was only using CGType and not TypeUID. > I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. > (just some loose ends maybe around opaque types and object runtime type information. > > > I had known record sizes, but not fields. Maybe this was a dilemna already before. > > > Anyway, the point is, up until now, record passing and returning by value I have handled > internally by passing around pointers and making copies as needed (at function start). > > > I forget exactly how returning works, I'll deal with that later. > > > Passing works as follows: > caller passes pointer to record > callee has a local variable of that type > callee early on copies pointer to local variable, and references that thereafter > > > This works and has almost no downside. > It is likely how the C compiler implements things anyway. > Except maybe for "small" records/structs. Some calling conventions > do allow for passing structs/records by value in registers. > > > Passing structs/records by value is relatively rare, so we probably don't care much. > > > Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of > passing structs by value? > > > There are multiple choices: > - no, leave it alone > - yes, change it unconditionally > - leave it as a const or var in M3C.m3 > - make it #ifdefed in the output .c > > > I think for returning, we have similar choices, but the frontend is willing > to do the transform and currently does -- a matter of a boolean in Target.i3. > > > This second question has equal quality debugging either way and needs no M3CG/frontend changes > either way. (though, you know, frontend is willing to make more transforms for > record return than record pass, I believe; it probably should be willing to do > more of the work.) > > > Very old compilers don't support passing structs by value? > Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. > > > --- #line directives or not? --- > > > Third question that has been bugging me. > The C backend can output #line directives. > So you step through the Modula-3 source. What people expect. > This was working, and probably still does. > I turned it off subject to a constant in the backend. > Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) > > This is great for, during backend development/debugging, the C compiler gives me C line numbers. > If the backend worked perfectly, this would be pointless. > I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. > There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. > > > What to do to cater to both/everyone? > I wish I could have multiple #line directives: > #line 123 foo.m3.c 456 foo.m3 > > > but that doesn't exit. > I could encode information in the file name: > #line 123 "foo.m3.c/456 foo.m3" > > > but that is imperfect; error messages will be good, but debugging won't work > > > I could leave it as an #ifdef in the code. > I do not believe the following works: > > #ifndef CLINE > #define LINE(cline, cfile, m3line, m3file) cline cfile > #else > #define LINE(cline, cfile, m3line, m3file) m3line m3file > #endif > #line LINE(123, "foo.c", 456, "foo.m3") > > > but I'll try it. > > > I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: > #ifndef CLINE > #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) > #endif > > This is bloated, but might be best. > > > if "#define LINE" works, great, but I doubt it will. > > > --- typeindex besides typeid? --- > > > I'm now doing a lot of lookups of typeids. > It'd be super nice if the frontend also maintained "small" incrementing > typeIndices that I could use to index into an array. > > > set_type_count(typeCount:CARDINAL); (* maybe *) > declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); > > > and thereafter, use typeIndex instead of typeId, an index into an array. > > > I've been tempted to ask for just: > declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); > > > but I realize that preserving the structural hash id is likely too useful/important, > either now or hypothetically. > > > There is then the question as to if begin_unit/end_unit reset typeIndex. > This somewhat depends on how the frontend works. > > > At some point I'd like to try outputing one C file across multiple units, > and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, > M3CG.import_library(static | dynamic | unknown), > so the backend knows which units definitely link together, > and guide ELF visibility/__declspec(dllimport,dllexport). > > > Given that, typeIndices would not reset upon end_unit. > There are challenges here, e.g. separate/incremental compilation. > I would like to amortize C compiler startup, as well, all the type declarations > would be shared across units, so the overall C source smaller. > Computer memory is vastly larger today than when CM3 was written and compilation > strategies have shifted significantly toward "whole program compilation". > We could do similar in the C backend..or leave it to the C compiler to try. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 12 00:19:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 22:19:23 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> References: , <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Message-ID: It is a mix of proposals and what-do-people-prefer-among-working-options andLet me try again. Just some of it. 1) Stronger typing on pop_param. Given INTERFACE I; PROCEDURE A(VAR a:INTEGER); PROCEDURE B() VAR b; BEGIN A(b); END B; I want void I__A(INTEGER* a); void I__B() { INTEGER b; A__I(&b) or A__I((INTEGER*)&b); } unnecessary casts are ok. This is not directly supported in M3CG: current: M3CG.pop_param(type := M3CG.Addr); (* Addr of what ? *) but it might be indirectly supported, i.e. if I look at the function type. Currently, on my machine, I cast to void*, but that isn't valid C++, only C. I might be able to cast the function itself to "untyped" and get away with it, but that is kind ugly too. proposal something like: M3CG.pop_param(CGType, TypeUID); but, furthermore, pop_struct doesn't need to be separate, so just: M3CG.pop_param(CGType, TypeUID, BitSize); and remove pop_struct. Much longer term, merely: M3CG.pop_param(TypeUID); suffices. CGType is generally redundant with TypeUIDs, however existing backends ignore TypeUIDs and get by with CGType. 2) Preference for how to handle passing structs by value in C backend? There are two obvious choices. I'm doing it "manually" because, perhaps, I didn't have good type information. I have good type information now, so I can use the C/C++ feature of passing structs by value, instead of passing a pointer and copying into a local. Works either way. No M3CG interface change. 3) Small dense TypeIndexes mostly-but-not-entirely in place of TypeUIDs. TypeUIDs imply a lot of "lookups" in the backend. Slow seeming. It'd be nice if we had a "linear" TypeIndex as well, that could be indices into a "full" array. Proposal: TypeIndex = CARDINAL; (* index into an array *) (* a separate typename here isn't all that valuable *) M3CG.declare_typeid or declare_typeindex or declare_type(TypeUID, TypeIndex); and possibly M3CG.declare_type_count(CARDINAL); (* maximum value of TypeIndex + 1, backends can allocate arrays of this size and the index by later TypeIndex *) TypeIndexes should take on the values roughly [0..N] where N is the number of types in the "program" (or unit..) and then replace TypeUID everywhere else with TypeIndex. Depending on how the frontend flows, it might not be able to compute TypeCount early enough. That is, I don't know if m3cg calls happen "during compilation" or only "at the end". As well, this does imply likely the same perf/lookups in the frontend. Moving rather than eliminating cost. However, it'd save it from multiple backends, and the frontend might already be paying this cost, I haven't looked yet. It is ok and works today, but I'd really rather have "small" dense integers that can index into an array than "random" integers that I'm forced to use something like a hash table or binary search a sorted array for. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu Subject: Re: [M3devel] many matters big and small esp. wrt C backend Date: Fri, 12 Apr 2013 07:12:42 +1000 To: jay.krell at cornell.edu Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 02:48:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 11 Apr 2013 19:48:11 -0500 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <5165AB6E.8060808@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> Message-ID: <516759CB.4090101@lcwb.coop> After a small clarification to m3-defn-complete.tex, I reran the autogeneration that produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. Many of these are checked-in to CVS, even though mechanically generated. All the html files have many differences. The current checked-in files were built by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, which generates HTML 4.0 Transitional. This information is visible within the html files. In addition, there are many instances of a few kinds of tag changes. Anecdotal examination revealed no content changes. Does anybody have any problems with checking these new versions in? Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, the older html files in cm3/doc/reference, and what we see at the elegosoft website? If I check in the regenerated files into CVS, will they be seen on the website? From wagner at elegosoft.com Fri Apr 12 08:30:30 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 12 Apr 2013 08:30:30 +0200 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <516759CB.4090101@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> Message-ID: <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> On Thu, 11 Apr 2013 19:48:11 -0500 "Rodney M. Bates" wrote: > After a small clarification to m3-defn-complete.tex, I reran the autogeneration that > produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. > Many of these are checked-in to CVS, even though mechanically generated. > > All the html files have many differences. The current checked-in files were built > by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, > which generates HTML 4.0 Transitional. This information is visible within the html files. > In addition, there are many instances of a few kinds of tag changes. Anecdotal examination > revealed no content changes. > > Does anybody have any problems with checking these new versions in? Just go ahead. > Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, > the older html files in cm3/doc/reference, and what we see at the elegosoft website? I think reference/complete is just the language reference, while the level above contains additional information from Critical Mass about the system and libraries. > If I check > in the regenerated files into CVS, will they be seen on the website? There is a script ship-cm3-www-doc which needs to be run; I can do that for you. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Apr 12 09:57:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 07:57:33 +0000 Subject: [M3devel] trestle grandChild.init 5 parameters? Message-ID: can anyone explain this? PROCEDURE InitChild (j: Join; ch: VBT.T; p: DeleteProc)= VAR grandChild := NEW(GrandChild, proc := p); child := StableVBT.New(grandChild); BEGIN EVAL grandChild.init(ch); (* line 41 *) j.trueChild := ch; EVAL j.init(child) END InitChild; There are only two obvious parameters. The generated code passes 5. I understand they could be default parameters, but I still don't see it. My particular problem is that type 79A5AEBB and/or 23E73F69 isn't declared. I'd like to know what they are. If I don't know the full information for every struct passed by value at the point of the call, I won't be able to use the C/C++ feature of passing structs by value. //line 41 "../src/trestle/InstalledVBT.m3" /* start_call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_address */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* check_nil */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_69_L_70))=(ADDRESS)(((ADDRESS)(L_67_L_68))); //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /*check_nil*/if(!L_69_L_70)M_InstalledVBT_L_37_CRASH(1316); //line 41 "../src/trestle/InstalledVBT.m3" /* call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_65_L_66))=(ADDRESS)(((ADDRESS)(((ADDRESS (__cdecl*)(DOTDOTDOT))L_69_L_70)( grandChild_L_45, ch_L_48, ((T79A5AEBB*)(*((ADDRESS*)(INT64_(232)+((ADDRESS)(*((ADDRESS*)(INT64_(984)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), ((T23E73F69*)(*((ADDRESS*)(INT64_(120)+((ADDRESS)(*((ADDRESS*)(INT64_(1008)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), INT64_(72)+((ADDRESS)(&L_35_L_36)))))); -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 17:19:09 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:19:09 -0500 Subject: [M3devel] Another CVS problem: adding a new file Message-ID: <516825ED.9010003@lcwb.coop> m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. cvs checkout says: cvs server: cannot find module `m3-defn-complete.pdf' - ignored When I try to add it, cvs add says: cvs add: `m3-defn-complete.pdf' added independently by second party and when I try to commit, cvs says: cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' cvs [commit aborted]: correct above errors first! From rodney_bates at lcwb.coop Fri Apr 12 17:38:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:38:11 -0500 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <516825ED.9010003@lcwb.coop> References: <516825ED.9010003@lcwb.coop> Message-ID: <51682A63.10709@lcwb.coop> On 04/12/2013 10:19 AM, Rodney M. Bates wrote: > m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. > cvs checkout says: > > cvs server: cannot find module `m3-defn-complete.pdf' - ignored > > When I try to add it, cvs add says: > > cvs add: `m3-defn-complete.pdf' added independently by second party > > and when I try to commit, cvs says: > > cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' > cvs [commit aborted]: correct above errors first! > > And after the above, when I do cvs update on a different computer, cvs says: cvs update: move away `complete/m3-defn-complete.pdf'; it is in the way C complete/m3-defn-complete.pdf And there is indeed a local file by this name. But MORE CVS/Entries gives: /Makefile/1.2/Thu Apr 29 17:20:18 2010// /m3-defn-completeimg1.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /m3-defn-completeimg2.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /nx_grp_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /prev_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /up_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ D/html//// /m3-defn-complete.html/1.4/Fri Apr 12 15:23:26 2013// /m3-defn-complete.ps/1.5/Fri Apr 12 15:23:28 2013/-kb/ /m3-defn-complete.tex/1.22/Wed Apr 10 16:44:07 2013// But again, cvs log m3-defn-complete.pdf gives: RCS file: /usr/cvs/cm3/doc/reference/complete/m3-defn-complete.pdf,v Working file: complete/m3-defn-complete.pdf head: 1.3 branch: locks: strict access list: symbolic names: release_CM3_5_8_6: 1.1.2.4 release_CM3_5_8_RC5: 1.1.2.2 release_branch_cm3_5_8: 1.1.0.2 keyword substitution: b total revisions: 7; selected revisions: 7 description: ---------------------------- revision 1.3 date: 2010-04-29 12:20:18 -0500; author: wagner; state: Exp; lines: +1420 -1410; commitid: HFcCg3x7BkM9jQwu; merge doc changes/extensions from release_branch_cm3_5_8 ---------------------------- which appears to tell me it's in the head and several branches. From jay.krell at cornell.edu Fri Apr 12 17:33:44 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 15:33:44 +0000 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <516825ED.9010003@lcwb.coop> References: <516825ED.9010003@lcwb.coop> Message-ID: CVS is awful. Try this: make sure you have "everything" "backed up" esp. m3-defn-complete.pdf rm -rf the local directory with m3-defn-complete.pdf (that you backed up) cvs upd -dAP to get it back if m3-defn-complete.pdf is there { rm m3-defn-complete.pdf cvs delete m3-defn-complete.pdf cvs commit m3-defn-complete.pdf } copy in your new m3-defn-complete.pdf cvs add m3-defn-complete.pdf cvs commit m3-defn-complete.pdf - Jay > Date: Fri, 12 Apr 2013 10:19:09 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Another CVS problem: adding a new file > > m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. > cvs checkout says: > > cvs server: cannot find module `m3-defn-complete.pdf' - ignored > > When I try to add it, cvs add says: > > cvs add: `m3-defn-complete.pdf' added independently by second party > > and when I try to commit, cvs says: > > cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' > cvs [commit aborted]: correct above errors first! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 12 18:05:34 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 16:05:34 +0000 Subject: [M3devel] m3front/Force_pair Message-ID: m3front/misc/CG.m3 PROCEDURE Force_pair (commute: BOOLEAN): BOOLEAN = (* Returns TRUE if the items are stacked in the wrong order *) VAR s1 := stack [SCheck (1, "Force_pair")].kind = VKind.Stacked; VAR s2 := stack [SCheck (2, "Force_pair")].kind = VKind.Stacked; BEGIN IF s1 AND s2 THEN (* both elements are already stacked *) RETURN FALSE; ELSIF s2 THEN (* bottom element is already stacked *) Force (); RETURN FALSE; ELSIF s1 THEN Swap (); Force (); IF commute THEN RETURN TRUE END; Swap (); RETURN FALSE; ELSE (* neither element is stacked *) Swap (); Force (); Swap (); Force (); RETURN FALSE; END; END Force_pair; Shouldn't the last part be: ELSE (* neither element is stacked *) IF commute THEN Force (); Swap (); Force (); RETURN TRUE; END; Swap (); Force (); Swap (); Force (); RETURN FALSE; END; ? Probably there is a way to write the function with less duplication. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 17:01:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:01:40 -0500 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> Message-ID: <516821D4.6050001@lcwb.coop> On 04/12/2013 01:30 AM, Olaf Wagner wrote: > On Thu, 11 Apr 2013 19:48:11 -0500 > "Rodney M. Bates" wrote: > >> After a small clarification to m3-defn-complete.tex, I reran the autogeneration that >> produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. >> Many of these are checked-in to CVS, even though mechanically generated. >> >> All the html files have many differences. The current checked-in files were built >> by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, >> which generates HTML 4.0 Transitional. This information is visible within the html files. >> In addition, there are many instances of a few kinds of tag changes. Anecdotal examination >> revealed no content changes. >> >> Does anybody have any problems with checking these new versions in? > > Just go ahead. Done, in the head. > >> Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, >> the older html files in cm3/doc/reference, and what we see at the elegosoft website? > > I think reference/complete is just the language reference, while the level above > contains additional information from Critical Mass about the system and libraries. > >> If I check >> in the regenerated files into CVS, will they be seen on the website? > > There is a script ship-cm3-www-doc which needs to be run; I can do that > for you. 1) Does it ship from head or release branch? 2) Can I do it myself, in case this happens again? > > Olaf > From jay.krell at cornell.edu Sat Apr 13 02:13:56 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Apr 2013 00:13:56 +0000 Subject: [M3devel] trestle grandChild.init 5 parameters? In-Reply-To: References: Message-ID: duh, 5 parameters, HighlightVBT: Public = Filter.T OBJECT METHODS init( ch: VBT.T; op: PaintOp.T := PaintOp.TransparentSwap; txt: Pixmap.T := Pixmap.Gray; READONLY delta := Point.T{h := 0, v := 1}): T END; note that if you make multiple calls, the compiler generates that const/static Point.T for each call, wasteful op and txt get single instanced. PaintOp.T = RECORD op:INTEGER END; Predefined = [0..16]; PixMap.T = RECORD pm: INTEGER END; Predefined = [0..2]; so then, this looks like a frontend bug. Of those three types, at least one is not described to the backend when compiling InstalledVBT.m3, inhibiting the C backend from using C's feature of passing structs by value, forcing us to generate code to pass a pointer and copy it into a local. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 12 Apr 2013 07:57:33 +0000 Subject: [M3devel] trestle grandChild.init 5 parameters? can anyone explain this? PROCEDURE InitChild (j: Join; ch: VBT.T; p: DeleteProc)= VAR grandChild := NEW(GrandChild, proc := p); child := StableVBT.New(grandChild); BEGIN EVAL grandChild.init(ch); (* line 41 *) j.trueChild := ch; EVAL j.init(child) END InitChild; There are only two obvious parameters. The generated code passes 5. I understand they could be default parameters, but I still don't see it. My particular problem is that type 79A5AEBB and/or 23E73F69 isn't declared. I'd like to know what they are. If I don't know the full information for every struct passed by value at the point of the call, I won't be able to use the C/C++ feature of passing structs by value. //line 41 "../src/trestle/InstalledVBT.m3" /* start_call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_address */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* check_nil */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_69_L_70))=(ADDRESS)(((ADDRESS)(L_67_L_68))); //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /*check_nil*/if(!L_69_L_70)M_InstalledVBT_L_37_CRASH(1316); //line 41 "../src/trestle/InstalledVBT.m3" /* call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_65_L_66))=(ADDRESS)(((ADDRESS)(((ADDRESS (__cdecl*)(DOTDOTDOT))L_69_L_70)( grandChild_L_45, ch_L_48, ((T79A5AEBB*)(*((ADDRESS*)(INT64_(232)+((ADDRESS)(*((ADDRESS*)(INT64_(984)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), ((T23E73F69*)(*((ADDRESS*)(INT64_(120)+((ADDRESS)(*((ADDRESS*)(INT64_(1008)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), INT64_(72)+((ADDRESS)(&L_35_L_36)))))); -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Sat Apr 13 02:39:06 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sat, 13 Apr 2013 00:39:06 +0000 Subject: [M3devel] EXT: Auto-generated html documentation and new tools In-Reply-To: <516759CB.4090101@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF0C2807AC@ATLEX04-SRV.SCIRES.LOCAL> Rodney: If I remember correctly, I think the files in cm3/doc are those that are supposed to form the doc subfolder of the cm3ide installation (formerly Reactor). I think there are some scripts that are supposed to update the generated files. Thus, back in the day when Critical Mass was selling their product, I think they ran the scripts to populate the doc folder before making a release of the product onto CD-ROM. Then, during the customer's installation, the doc folder would get pushed to the customer's hard drive. I know that cm3ide expects to find certain information in the doc folder. Hope this helps a bit. --Randy -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Thursday, April 11, 2013 8:48 PM To: m3devel Subject: EXT:[M3devel] Auto-generated html documentation and new tools After a small clarification to m3-defn-complete.tex, I reran the autogeneration that produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. Many of these are checked-in to CVS, even though mechanically generated. All the html files have many differences. The current checked-in files were built by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, which generates HTML 4.0 Transitional. This information is visible within the html files. In addition, there are many instances of a few kinds of tag changes. Anecdotal examination revealed no content changes. Does anybody have any problems with checking these new versions in? Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, the older html files in cm3/doc/reference, and what we see at the elegosoft website? If I check in the regenerated files into CVS, will they be seen on the website? From jay.krell at cornell.edu Sat Apr 13 04:44:40 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Apr 2013 02:44:40 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: References: , , <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>, Message-ID: > M3CG.pop_param(CGType, TypeUID, BitSize); I was able to get away without this because I know the signature of the function for direct calls. So far I don't strongly type function pointers. And because of the static link, I'm not sure I can. I'm not sure it matters. For debugging, it only matters when you step through to the called function, and I declare them all now quite typefully. I still think this is a very good idea though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 11 Apr 2013 22:19:23 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] many matters big and small esp. wrt C backend It is a mix of proposals and what-do-people-prefer-among-working-options and Let me try again. Just some of it. 1) Stronger typing on pop_param. Given INTERFACE I; PROCEDURE A(VAR a:INTEGER); PROCEDURE B() VAR b; BEGIN A(b); END B; I want void I__A(INTEGER* a); void I__B() { INTEGER b; A__I(&b) or A__I((INTEGER*)&b); } unnecessary casts are ok. This is not directly supported in M3CG: current: M3CG.pop_param(type := M3CG.Addr); (* Addr of what ? *) but it might be indirectly supported, i.e. if I look at the function type. Currently, on my machine, I cast to void*, but that isn't valid C++, only C. I might be able to cast the function itself to "untyped" and get away with it, but that is kind ugly too. proposal something like: M3CG.pop_param(CGType, TypeUID); but, furthermore, pop_struct doesn't need to be separate, so just: M3CG.pop_param(CGType, TypeUID, BitSize); and remove pop_struct. Much longer term, merely: M3CG.pop_param(TypeUID); suffices. CGType is generally redundant with TypeUIDs, however existing backends ignore TypeUIDs and get by with CGType. 2) Preference for how to handle passing structs by value in C backend? There are two obvious choices. I'm doing it "manually" because, perhaps, I didn't have good type information. I have good type information now, so I can use the C/C++ feature of passing structs by value, instead of passing a pointer and copying into a local. Works either way. No M3CG interface change. 3) Small dense TypeIndexes mostly-but-not-entirely in place of TypeUIDs. TypeUIDs imply a lot of "lookups" in the backend. Slow seeming. It'd be nice if we had a "linear" TypeIndex as well, that could be indices into a "full" array. Proposal: TypeIndex = CARDINAL; (* index into an array *) (* a separate typename here isn't all that valuable *) M3CG.declare_typeid or declare_typeindex or declare_type(TypeUID, TypeIndex); and possibly M3CG.declare_type_count(CARDINAL); (* maximum value of TypeIndex + 1, backends can allocate arrays of this size and the index by later TypeIndex *) TypeIndexes should take on the values roughly [0..N] where N is the number of types in the "program" (or unit..) and then replace TypeUID everywhere else with TypeIndex. Depending on how the frontend flows, it might not be able to compute TypeCount early enough. That is, I don't know if m3cg calls happen "during compilation" or only "at the end". As well, this does imply likely the same perf/lookups in the frontend. Moving rather than eliminating cost. However, it'd save it from multiple backends, and the frontend might already be paying this cost, I haven't looked yet. It is ok and works today, but I'd really rather have "small" dense integers that can index into an array than "random" integers that I'm forced to use something like a hash table or binary search a sorted array for. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu Subject: Re: [M3devel] many matters big and small esp. wrt C backend Date: Fri, 12 Apr 2013 07:12:42 +1000 To: jay.krell at cornell.edu Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 13 08:52:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 13 Apr 2013 08:52:28 +0200 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: References: <516825ED.9010003@lcwb.coop> Message-ID: Never ending story :). To make it short - let's move to git! :) On Apr 12, 2013, at 5:33 PM, Jay K wrote: > CVS is awful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 13 14:44:34 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 13 Apr 2013 14:44:34 +0200 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <516821D4.6050001@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> <516821D4.6050001@lcwb.coop> Message-ID: <20130413144434.63c30578edad59441166d5e9@elegosoft.com> On Fri, 12 Apr 2013 10:01:40 -0500 "Rodney M. Bates" wrote: > On 04/12/2013 01:30 AM, Olaf Wagner wrote: > > On Thu, 11 Apr 2013 19:48:11 -0500 > > "Rodney M. Bates" wrote: > > > >> After a small clarification to m3-defn-complete.tex, I reran the autogeneration that > >> produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. > >> Many of these are checked-in to CVS, even though mechanically generated. > >> > >> All the html files have many differences. The current checked-in files were built > >> by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, > >> which generates HTML 4.0 Transitional. This information is visible within the html files. > >> In addition, there are many instances of a few kinds of tag changes. Anecdotal examination > >> revealed no content changes. > >> > >> Does anybody have any problems with checking these new versions in? > > > > Just go ahead. > > Done, in the head. I've checked out head and ran the scripts; results see below. > > > > >> Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, > >> the older html files in cm3/doc/reference, and what we see at the elegosoft website? > > > > I think reference/complete is just the language reference, while the level above > > contains additional information from Critical Mass about the system and libraries. > > > >> If I check > >> in the regenerated files into CVS, will they be seen on the website? > > > > There is a script ship-cm3-www-doc which needs to be run; I can do that > > for you. > > 1) Does it ship from head or release branch? The scripts just ships what it finds in the workspace. I think we only ever shipped from head, but am not sure. > 2) Can I do it myself, in case this happens again? You need to be in the m3 group I think, but that's the case: % id rodney uid=6011(rodney) gid=6011(rodney) groups=6011(rodney),200(m3),10004(tinderbox) So you should be able to ship the documentation yourself, too. Olaf --- Updated documents --- birch [/var/www/modula3.elegosoft.com/cm3/doc] wagner % find . -mtime -1 -print | xargs ls -ld drwxrwsr-x 8 www-data m3 4096 2013-04-13 14:36 . drwxrwsr-x 8 root m3 4096 2013-04-13 14:36 ./help -rwxrwsr-x 1 wagner m3 39110 2013-04-13 14:36 ./help/bib.html drwxrwsr-x 4 root m3 4096 2013-04-13 14:36 ./help/cm3 -rw-rwSr-- 1 wagner m3 5215 2013-04-13 14:36 ./help/cm3/acks.html -rw-rwSr-- 1 wagner m3 2055 2013-04-13 14:36 ./help/cm3/cm3.html -rw-rwSr-- 1 wagner m3 4225 2013-04-13 14:36 ./help/cm3/cm3-quickref.html -rw-rwSr-- 1 wagner m3 798 2013-04-13 14:36 ./help/cm3/compiling.html -rw-rwSr-- 1 wagner m3 5198 2013-04-13 14:36 ./help/cm3/debugging.html -rw-rwSr-- 1 wagner m3 2129 2013-04-13 14:36 ./help/cm3/files.html -rw-rwSr-- 1 wagner m3 2033 2013-04-13 14:36 ./help/cm3/gc.html -rw-rwSr-- 1 wagner m3 5868 2013-04-13 14:36 ./help/cm3/gnuemacs.html -rw-rwSr-- 1 wagner m3 11684 2013-04-13 14:36 ./help/cm3/history.html -rw-rwSr-- 1 wagner m3 3146 2013-04-13 14:36 ./help/cm3/m3args.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./help/cm3/m3build -rw-rwSr-- 1 wagner m3 534 2013-04-13 14:36 ./help/cm3/m3build/emacs.html -rw-rwSr-- 1 wagner m3 1936 2013-04-13 14:36 ./help/cm3/m3build/exports.html -rw-rwSr-- 1 wagner m3 652 2013-04-13 14:36 ./help/cm3/m3build/foreign.html -rw-rwSr-- 1 wagner m3 3371 2013-04-13 14:36 ./help/cm3/m3build/generics.html -rw-rwSr-- 1 wagner m3 1216 2013-04-13 14:36 ./help/cm3/m3build/hiding.html -rw-rwSr-- 1 wagner m3 1258 2013-04-13 14:36 ./help/cm3/m3build/imports.html -rw-rwSr-- 1 wagner m3 3316 2013-04-13 14:36 ./help/cm3/m3build/m3build.html -rw-rwSr-- 1 wagner m3 951 2013-04-13 14:36 ./help/cm3/m3build/m3makefile.html -rw-rwSr-- 1 wagner m3 1246 2013-04-13 14:36 ./help/cm3/m3build/m3options.html -rw-rwSr-- 1 wagner m3 2484 2013-04-13 14:36 ./help/cm3/m3build/machine.html -rw-rwSr-- 1 wagner m3 763 2013-04-13 14:36 ./help/cm3/m3build/manpage.html -rw-rwSr-- 1 wagner m3 1131 2013-04-13 14:36 ./help/cm3/m3build/misc.html -rw-rwSr-- 1 wagner m3 662 2013-04-13 14:36 ./help/cm3/m3build/netobj.html -rw-rwSr-- 1 wagner m3 947 2013-04-13 14:36 ./help/cm3/m3build/noweb.html -rw-rwSr-- 1 wagner m3 3366 2013-04-13 14:36 ./help/cm3/m3build/options.html -rw-rwSr-- 1 wagner m3 1525 2013-04-13 14:36 ./help/cm3/m3build/overrides.html -rw-rwSr-- 1 wagner m3 956 2013-04-13 14:36 ./help/cm3/m3build/progs.html -rw-rwSr-- 1 wagner m3 958 2013-04-13 14:36 ./help/cm3/m3build/resources.html -rw-rwSr-- 1 wagner m3 2811 2013-04-13 14:36 ./help/cm3/m3build/sources.html -rw-rwSr-- 1 wagner m3 644 2013-04-13 14:36 ./help/cm3/m3ship.html -rw-rwSr-- 1 wagner m3 410 2013-04-13 14:36 ./help/cm3/m3where.html -rw-rwSr-- 1 wagner m3 18647 2013-04-13 14:36 ./help/cm3/old-bib.html -rw-rwSr-- 1 wagner m3 2816 2013-04-13 14:36 ./help/cm3/packages.html -rw-rwSr-- 1 wagner m3 10450 2013-04-13 14:36 ./help/cm3/pprint.html -rw-rwSr-- 1 wagner m3 10432 2013-04-13 14:36 ./help/cm3/pragmas.html -rw-rwSr-- 1 wagner m3 33312 2013-04-13 14:36 ./help/cm3/quake.html -rw-rwSr-- 1 wagner m3 3660 2013-04-13 14:36 ./help/cm3/restrictions.html -rw-rwSr-- 1 wagner m3 3449 2013-04-13 14:36 ./help/cm3/runtime.html -rw-rwSr-- 1 wagner m3 3346 2013-04-13 14:36 ./help/cm3/scheduler.html -rw-rwSr-- 1 wagner m3 3054 2013-04-13 14:36 ./help/cm3/showheap.html -rw-rwSr-- 1 wagner m3 947 2013-04-13 14:36 ./help/cm3/shownew.html -rw-rwSr-- 1 wagner m3 1778 2013-04-13 14:36 ./help/cm3/showthread.html -rw-rwSr-- 1 wagner m3 1339 2013-04-13 14:36 ./help/cm3/signals.html -rwxrwsr-x 1 wagner m3 4194 2013-04-13 14:36 ./help/concise-bib.html -rwxrwsr-x 1 wagner m3 20380 2013-04-13 14:36 ./help/getting-started.html -rwxrwsr-x 1 wagner m3 3948 2013-04-13 14:36 ./help/index.html -rwxrwsr-x 1 wagner m3 51629 2013-04-13 14:36 ./help/interfaces.html drwxrwsr-x 2 wagner m3 4096 2013-04-13 14:36 ./help/m3gdb -rw-rwSr-- 1 wagner m3 53432 2013-04-13 14:36 ./help/m3gdb/m3gdb.docbook -rw-rwSr-- 1 wagner m3 63275 2013-04-13 14:36 ./help/m3gdb/m3gdb-onepage.html -rw-rwSr-- 1 wagner m3 4133 2013-04-13 14:36 ./index.html drwxrwsr-x 2 wagner m3 4096 2013-04-13 14:36 ./notes -rw-rw-r-- 1 wagner m3 2401 2013-04-13 14:36 ./notes/building-old.txt -rw-rw-r-- 1 wagner m3 16 2013-04-13 14:36 ./notes/object-model.txt -rw-rw-r-- 1 wagner m3 12811 2013-04-13 14:36 ./notes/porting.txt -rw-rw-r-- 1 wagner m3 8642 2013-04-13 14:36 ./notes/todo.txt -rw-rwSr-- 1 wagner m3 303039 2013-04-13 14:36 ./PkgDesc drwxrwsr-x 4 root m3 4096 2013-04-13 14:36 ./reference drwxrwxr-x 4 wagner m3 4096 2013-04-13 14:36 ./reference/complete drwxrwxr-x 2 wagner wagner 4096 2013-04-13 14:36 ./reference/complete/html -rw-r--r-- 1 wagner wagner 3945 2013-04-13 14:36 ./reference/complete/html/0_0_0_11_4_1_Interfaces.html -rw-r--r-- 1 wagner wagner 5814 2013-04-13 14:36 ./reference/complete/html/0_0_0_21_4_2_Objects.html -rw-r--r-- 1 wagner wagner 3937 2013-04-13 14:36 ./reference/complete/html/0_0_0_31_4_3_Generics.html -rw-r--r-- 1 wagner wagner 4981 2013-04-13 14:36 ./reference/complete/html/0_0_0_41_4_4_Threads.html -rw-r--r-- 1 wagner wagner 4554 2013-04-13 14:36 ./reference/complete/html/0_0_0_51_4_5_Safety.html -rw-r--r-- 1 wagner wagner 5003 2013-04-13 14:36 ./reference/complete/html/0_0_0_61_4_6_Garbage.html -rw-r--r-- 1 wagner wagner 3845 2013-04-13 14:36 ./reference/complete/html/0_0_0_71_4_7_Exceptions.html -rw-r--r-- 1 wagner wagner 4413 2013-04-13 14:36 ./reference/complete/html/0_0_0_81_4_8_Type.html -rw-r--r-- 1 wagner wagner 4122 2013-04-13 14:36 ./reference/complete/html/0_0_0_91_4_9_Simplicity.html -rw-r--r-- 1 wagner wagner 4318 2013-04-13 14:36 ./reference/complete/html/1_1History.html -rw-r--r-- 1 wagner wagner 7264 2013-04-13 14:36 ./reference/complete/html/1_2Perspective.html -rw-r--r-- 1 wagner wagner 2027 2013-04-13 14:36 ./reference/complete/html/1_3Overview.html -rw-r--r-- 1 wagner wagner 3914 2013-04-13 14:36 ./reference/complete/html/1_4Features.html -rw-r--r-- 1 wagner wagner 2635 2013-04-13 14:36 ./reference/complete/html/1_Introduction.html -rw-r--r-- 1 wagner wagner 5124 2013-04-13 14:36 ./reference/complete/html/2_1Definitions.html -rw-r--r-- 1 wagner wagner 6857 2013-04-13 14:36 ./reference/complete/html/2_2_10Subtyping_rules.html -rw-r--r-- 1 wagner wagner 2159 2013-04-13 14:36 ./reference/complete/html/2_2_11Predeclared_opaque.html -rw-r--r-- 1 wagner wagner 6907 2013-04-13 14:36 ./reference/complete/html/2_2_1Ordinal_types.html -rw-r--r-- 1 wagner wagner 2095 2013-04-13 14:36 ./reference/complete/html/2_2_2Floating_point_types.html -rw-r--r-- 1 wagner wagner 6083 2013-04-13 14:36 ./reference/complete/html/2_2_3Arrays.html -rw-r--r-- 1 wagner wagner 4807 2013-04-13 14:36 ./reference/complete/html/2_2_4Records.html -rw-r--r-- 1 wagner wagner 2695 2013-04-13 14:36 ./reference/complete/html/2_2_5Packed_types.html -rw-r--r-- 1 wagner wagner 2538 2013-04-13 14:36 ./reference/complete/html/2_2_6Sets.html -rw-r--r-- 1 wagner wagner 5344 2013-04-13 14:36 ./reference/complete/html/2_2_7References.html -rw-r--r-- 1 wagner wagner 7931 2013-04-13 14:36 ./reference/complete/html/2_2_8Procedures.html -rw-r--r-- 1 wagner wagner 11577 2013-04-13 14:36 ./reference/complete/html/2_2_9Objects.html -rw-r--r-- 1 wagner wagner 5975 2013-04-13 14:36 ./reference/complete/html/2_2Types.html -rw-r--r-- 1 wagner wagner 2406 2013-04-13 14:36 ./reference/complete/html/2_3_10Exit.html -rw-r--r-- 1 wagner wagner 2917 2013-04-13 14:36 ./reference/complete/html/2_3_11Return.html -rw-r--r-- 1 wagner wagner 3079 2013-04-13 14:36 ./reference/complete/html/2_3_12If.html -rw-r--r-- 1 wagner wagner 2013 2013-04-13 14:36 ./reference/complete/html/2_3_13While.html -rw-r--r-- 1 wagner wagner 2014 2013-04-13 14:36 ./reference/complete/html/2_3_14Repeat.html -rw-r--r-- 1 wagner wagner 3114 2013-04-13 14:36 ./reference/complete/html/2_3_15With.html -rw-r--r-- 1 wagner wagner 4537 2013-04-13 14:36 ./reference/complete/html/2_3_16For.html -rw-r--r-- 1 wagner wagner 3315 2013-04-13 14:36 ./reference/complete/html/2_3_17Case.html -rw-r--r-- 1 wagner wagner 5596 2013-04-13 14:36 ./reference/complete/html/2_3_18Typecase.html -rw-r--r-- 1 wagner wagner 2207 2013-04-13 14:36 ./reference/complete/html/2_3_19Lock.html -rw-r--r-- 1 wagner wagner 5701 2013-04-13 14:36 ./reference/complete/html/2_3_1Assignment.html -rw-r--r-- 1 wagner wagner 2603 2013-04-13 14:36 ./reference/complete/html/2_3_20Inc_Dec.html -rw-r--r-- 1 wagner wagner 6677 2013-04-13 14:36 ./reference/complete/html/2_3_2Procedure_call.html -rw-r--r-- 1 wagner wagner 2111 2013-04-13 14:36 ./reference/complete/html/2_3_3Eval.html -rw-r--r-- 1 wagner wagner 2253 2013-04-13 14:36 ./reference/complete/html/2_3_4Block_statement.html -rw-r--r-- 1 wagner wagner 2391 2013-04-13 14:36 ./reference/complete/html/2_3_5Sequential_composition.html -rw-r--r-- 1 wagner wagner 2430 2013-04-13 14:36 ./reference/complete/html/2_3_6Raise.html -rw-r--r-- 1 wagner wagner 6290 2013-04-13 14:36 ./reference/complete/html/2_3_7Try_Except.html -rw-r--r-- 1 wagner wagner 2388 2013-04-13 14:36 ./reference/complete/html/2_3_8Try_Finally.html -rw-r--r-- 1 wagner wagner 2051 2013-04-13 14:36 ./reference/complete/html/2_3_9Loop.html -rw-r--r-- 1 wagner wagner 5794 2013-04-13 14:36 ./reference/complete/html/2_3Statements.html -rw-r--r-- 1 wagner wagner 2088 2013-04-13 14:36 ./reference/complete/html/2_4_1Types.html -rw-r--r-- 1 wagner wagner 2263 2013-04-13 14:36 ./reference/complete/html/2_4_2Constants.html -rw-r--r-- 1 wagner wagner 4207 2013-04-13 14:36 ./reference/complete/html/2_4_3Variables.html -rw-r--r-- 1 wagner wagner 3001 2013-04-13 14:36 ./reference/complete/html/2_4_4Procedures.html -rw-r--r-- 1 wagner wagner 2296 2013-04-13 14:36 ./reference/complete/html/2_4_5Exceptions.html -rw-r--r-- 1 wagner wagner 2892 2013-04-13 14:36 ./reference/complete/html/2_4_6Opaque_types.html -rw-r--r-- 1 wagner wagner 5433 2013-04-13 14:36 ./reference/complete/html/2_4_7Revelations.html -rw-r--r-- 1 wagner wagner 3462 2013-04-13 14:36 ./reference/complete/html/2_4_8Recursive_declarations.html -rw-r--r-- 1 wagner wagner 3798 2013-04-13 14:36 ./reference/complete/html/2_4Declarations.html -rw-r--r-- 1 wagner wagner 3383 2013-04-13 14:36 ./reference/complete/html/2_5_1Import_statements.html -rw-r--r-- 1 wagner wagner 2425 2013-04-13 14:36 ./reference/complete/html/2_5_2Interfaces.html -rw-r--r-- 1 wagner wagner 5208 2013-04-13 14:36 ./reference/complete/html/2_5_3Modules.html -rw-r--r-- 1 wagner wagner 3081 2013-04-13 14:36 ./reference/complete/html/2_5_4Example_module.html -rw-r--r-- 1 wagner wagner 6960 2013-04-13 14:36 ./reference/complete/html/2_5_5Generics.html -rw-r--r-- 1 wagner wagner 2752 2013-04-13 14:36 ./reference/complete/html/2_5_6Initialization.html -rw-r--r-- 1 wagner wagner 2719 2013-04-13 14:36 ./reference/complete/html/2_5_7Safety.html -rw-r--r-- 1 wagner wagner 5991 2013-04-13 14:36 ./reference/complete/html/2_5Modules_interfaces.html -rw-r--r-- 1 wagner wagner 9402 2013-04-13 14:36 ./reference/complete/html/2_6_10Arithmetic_operations.html -rw-r--r-- 1 wagner wagner 5613 2013-04-13 14:36 ./reference/complete/html/2_6_11Relations.html -rw-r--r-- 1 wagner wagner 2602 2013-04-13 14:36 ./reference/complete/html/2_6_12Boolean_operations.html -rw-r--r-- 1 wagner wagner 8300 2013-04-13 14:36 ./reference/complete/html/2_6_13Type_operations.html -rw-r--r-- 1 wagner wagner 2147 2013-04-13 14:36 ./reference/complete/html/2_6_14Text_operations.html -rw-r--r-- 1 wagner wagner 2741 2013-04-13 14:36 ./reference/complete/html/2_6_15Constant_expressions.html -rw-r--r-- 1 wagner wagner 4521 2013-04-13 14:36 ./reference/complete/html/2_6_1Conventions_describing.html -rw-r--r-- 1 wagner wagner 5968 2013-04-13 14:36 ./reference/complete/html/2_6_2Operation_syntax.html -rw-r--r-- 1 wagner wagner 7552 2013-04-13 14:36 ./reference/complete/html/2_6_3Designators.html -rw-r--r-- 1 wagner wagner 5538 2013-04-13 14:36 ./reference/complete/html/2_6_4Numeric_literals.html -rw-r--r-- 1 wagner wagner 5517 2013-04-13 14:36 ./reference/complete/html/2_6_5Text_character.html -rw-r--r-- 1 wagner wagner 2018 2013-04-13 14:36 ./reference/complete/html/2_6_6Nil.html -rw-r--r-- 1 wagner wagner 2005 2013-04-13 14:36 ./reference/complete/html/2_6_7Function_application.html -rw-r--r-- 1 wagner wagner 4701 2013-04-13 14:36 ./reference/complete/html/2_6_8Set_array.html -rw-r--r-- 1 wagner wagner 5235 2013-04-13 14:36 ./reference/complete/html/2_6_9New.html -rw-r--r-- 1 wagner wagner 4118 2013-04-13 14:36 ./reference/complete/html/2_6Expressions.html -rw-r--r-- 1 wagner wagner 7050 2013-04-13 14:36 ./reference/complete/html/2_7Unsafe_operations.html -rw-r--r-- 1 wagner wagner 2724 2013-04-13 14:36 ./reference/complete/html/2_8_10Expression_production.html -rw-r--r-- 1 wagner wagner 2108 2013-04-13 14:36 ./reference/complete/html/2_8_11Miscellaneous_product.html -rw-r--r-- 1 wagner wagner 3747 2013-04-13 14:36 ./reference/complete/html/2_8_12Token_productions.html -rw-r--r-- 1 wagner wagner 2518 2013-04-13 14:36 ./reference/complete/html/2_8_1Keywords.html -rw-r--r-- 1 wagner wagner 2346 2013-04-13 14:36 ./reference/complete/html/2_8_2Reserved_identifiers.html -rw-r--r-- 1 wagner wagner 2132 2013-04-13 14:36 ./reference/complete/html/2_8_3Operators.html -rw-r--r-- 1 wagner wagner 1990 2013-04-13 14:36 ./reference/complete/html/2_8_4Comments.html -rw-r--r-- 1 wagner wagner 2863 2013-04-13 14:36 ./reference/complete/html/2_8_5Pragmas.html -rw-r--r-- 1 wagner wagner 3274 2013-04-13 14:36 ./reference/complete/html/2_8_6Conventions_syntax.html -rw-r--r-- 1 wagner wagner 3429 2013-04-13 14:36 ./reference/complete/html/2_8_7Compilation_unit.html -rw-r--r-- 1 wagner wagner 3102 2013-04-13 14:36 ./reference/complete/html/2_8_8Statement_productions.html -rw-r--r-- 1 wagner wagner 2883 2013-04-13 14:36 ./reference/complete/html/2_8_9Type_productions.html -rw-r--r-- 1 wagner wagner 3389 2013-04-13 14:36 ./reference/complete/html/2_8Syntax.html -rw-r--r-- 1 wagner wagner 5009 2013-04-13 14:36 ./reference/complete/html/About_authors.html -rw-r--r-- 1 wagner wagner 2407 2013-04-13 14:36 ./reference/complete/html/About_this_document.html -rw-r--r-- 1 wagner wagner 4672 2013-04-13 14:36 ./reference/complete/html/Acknowledgments.html -rw-r--r-- 1 wagner wagner 3951 2013-04-13 14:36 ./reference/complete/html/Contents.html -rw-rw-r-- 1 wagner wagner 178 2013-04-13 14:36 ./reference/complete/html/img1.png -rw-rw-r-- 1 wagner wagner 348 2013-04-13 14:36 ./reference/complete/html/img2.png -rw-r--r-- 1 wagner wagner 1752 2013-04-13 14:36 ./reference/complete/html/index.html -rw-r--r-- 1 wagner wagner 1752 2013-04-13 14:36 ./reference/complete/html/m3-defn-complete.html -rw-r--r-- 1 wagner wagner 5770 2013-04-13 14:36 ./reference/complete/html/Modula_3_Language_definitio.html -rw-rw-r-- 1 wagner wagner 272 2013-04-13 14:36 ./reference/complete/html/next_g.png -rw-rw-r-- 1 wagner wagner 245 2013-04-13 14:36 ./reference/complete/html/next.png -rw-rw-r-- 1 wagner wagner 327 2013-04-13 14:36 ./reference/complete/html/prev_g.png -rw-rw-r-- 1 wagner wagner 279 2013-04-13 14:36 ./reference/complete/html/prev.png -rw-rw-r-- 1 wagner wagner 231 2013-04-13 14:36 ./reference/complete/html/up_g.png -rw-rw-r-- 1 wagner wagner 211 2013-04-13 14:36 ./reference/complete/html/up.png -rw-r--r-- 1 wagner wagner 185985 2013-04-13 14:36 ./reference/complete/m3-defn-complete.html -rw-rw-r-- 1 wagner wagner 178 2013-04-13 14:36 ./reference/complete/m3-defn-completeimg1.png -rw-rw-r-- 1 wagner wagner 348 2013-04-13 14:36 ./reference/complete/m3-defn-completeimg2.png -rw-rw-r-- 1 wagner wagner 307268 2013-04-13 14:36 ./reference/complete/m3-defn-complete.pdf -rw-rw-r-- 1 wagner wagner 335290 2013-04-13 14:36 ./reference/complete/m3-defn-complete.ps -rw-rw-r-- 1 wagner wagner 163695 2013-04-13 14:36 ./reference/complete/m3-defn-complete.tex -rw-rw-r-- 1 wagner wagner 1329 2013-04-13 14:36 ./reference/complete/Makefile -rw-rw-r-- 1 wagner wagner 386 2013-04-13 14:36 ./reference/complete/nx_grp_g.png -rw-rw-r-- 1 wagner wagner 327 2013-04-13 14:36 ./reference/complete/prev_g.png -rw-rw-r-- 1 wagner wagner 231 2013-04-13 14:36 ./reference/complete/up_g.png -rw-rw-r-- 1 wagner m3 10933 2013-04-13 14:36 ./reference/syntax.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./src_reports drwxrwsr-x 2 root m3 4096 2013-04-13 14:36 ./src_reports/blue_paper -r-xrwsr-x 1 wagner m3 34882 2013-04-13 14:36 ./src_reports/blue_paper/architecture_full.gif -r-xrwsr-x 1 wagner m3 20579 2013-04-13 14:36 ./src_reports/blue_paper/architecture.gif -r-xrwsr-x 1 wagner m3 14458 2013-04-13 14:36 ./src_reports/blue_paper/bg.gif -r-xrwsr-x 1 wagner m3 8713 2013-04-13 14:36 ./src_reports/blue_paper/blueLogo.gif -r-xrwsr-x 1 wagner m3 848 2013-04-13 14:36 ./src_reports/blue_paper/dark.gif -rwxrwsr-x 1 wagner m3 37227 2013-04-13 14:36 ./src_reports/blue_paper/index.html -r-xrwsr-x 1 wagner m3 840 2013-04-13 14:36 ./src_reports/blue_paper/light.gif -r-xrwsr-x 1 wagner m3 98030 2013-04-13 14:36 ./src_reports/blue_paper/screen_full.gif -r-xrwsr-x 1 wagner m3 53169 2013-04-13 14:36 ./src_reports/blue_paper/screen.gif -r-xrwsr-x 1 wagner m3 104 2013-04-13 14:36 ./src_reports/doc.gif -r-xrwsr-x 1 wagner m3 683909 2013-04-13 14:36 ./src_reports/formsvbt.pdf -r-xrwsr-x 1 wagner m3 346858 2013-04-13 14:36 ./src_reports/formsvbt.ps.gz -rwxrwsr-x 1 wagner m3 8662 2013-04-13 14:36 ./src_reports/index.html -rwxrwsr-x 1 wagner m3 1624 2013-04-13 14:36 ./src_reports/license.html -rwxrwsr-x 1 wagner m3 45843 2013-04-13 14:36 ./src_reports/m3poster.ps -rwxrwsr-x 1 wagner m3 44737 2013-04-13 14:36 ./src_reports/m3syntax.ps -rwxrwsr-x 1 wagner m3 31535 2013-04-13 14:36 ./src_reports/m3tokens.ps -r-xrwsr-x 1 wagner m3 235733 2013-04-13 14:36 ./src_reports/obliq.pdf -rwxrwsr-x 1 wagner m3 806862 2013-04-13 14:36 ./src_reports/obliq.ps -r-xrwsr-x 1 wagner m3 704201 2013-04-13 14:36 ./src_reports/src-068.pdf -rwxrwsr-x 1 wagner m3 2236519 2013-04-13 14:36 ./src_reports/src-068.ps -r-xrwsr-x 1 wagner m3 406003 2013-04-13 14:36 ./src_reports/src-069.pdf -r-xrwsr-x 1 wagner m3 554874 2013-04-13 14:36 ./src_reports/src-069.ps.gz -r-xrwsr-x 1 wagner m3 502259 2013-04-13 14:36 ./src_reports/src-113.pdf -rwxrwsr-x 1 wagner m3 487058 2013-04-13 14:36 ./src_reports/src-113.ps -r-xrwsr-x 1 wagner m3 261887 2013-04-13 14:36 ./src_reports/src-115.pdf -rwxrwsr-x 1 wagner m3 227121 2013-04-13 14:36 ./src_reports/src-115.ps -r-xrwsr-x 1 wagner m3 609326 2013-04-13 14:36 ./src_reports/vbtkit.pdf -rwxrwsr-x 1 wagner m3 734907 2013-04-13 14:36 ./src_reports/vbtkit.ps drwxrwsr-x 5 root m3 4096 2013-04-13 14:36 ./tutorial -rwxrwsr-x 1 wagner m3 2665 2013-04-13 14:36 ./tutorial/index.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/m3 -rwxrwsr-x 1 wagner m3 2081 2013-04-13 14:36 ./tutorial/m3/m3_10.html -rwxrwsr-x 1 wagner m3 1680 2013-04-13 14:36 ./tutorial/m3/m3_11.html -rwxrwsr-x 1 wagner m3 2312 2013-04-13 14:36 ./tutorial/m3/m3_12.html -rwxrwsr-x 1 wagner m3 1738 2013-04-13 14:36 ./tutorial/m3/m3_13.html -rwxrwsr-x 1 wagner m3 3033 2013-04-13 14:36 ./tutorial/m3/m3_14.html -rwxrwsr-x 1 wagner m3 1314 2013-04-13 14:36 ./tutorial/m3/m3_15.html -rwxrwsr-x 1 wagner m3 2327 2013-04-13 14:36 ./tutorial/m3/m3_16.html -rwxrwsr-x 1 wagner m3 2630 2013-04-13 14:36 ./tutorial/m3/m3_17.html -rwxrwsr-x 1 wagner m3 1989 2013-04-13 14:36 ./tutorial/m3/m3_18.html -rwxrwsr-x 1 wagner m3 1768 2013-04-13 14:36 ./tutorial/m3/m3_19.html -rwxrwsr-x 1 wagner m3 1636 2013-04-13 14:36 ./tutorial/m3/m3_1.html -rwxrwsr-x 1 wagner m3 4358 2013-04-13 14:36 ./tutorial/m3/m3_20.html -rwxrwsr-x 1 wagner m3 1273 2013-04-13 14:36 ./tutorial/m3/m3_21.html -rwxrwsr-x 1 wagner m3 1247 2013-04-13 14:36 ./tutorial/m3/m3_22.html -rwxrwsr-x 1 wagner m3 3723 2013-04-13 14:36 ./tutorial/m3/m3_23.html -rwxrwsr-x 1 wagner m3 1621 2013-04-13 14:36 ./tutorial/m3/m3_24.html -rwxrwsr-x 1 wagner m3 2050 2013-04-13 14:36 ./tutorial/m3/m3_25.html -rwxrwsr-x 1 wagner m3 1373 2013-04-13 14:36 ./tutorial/m3/m3_26.html -rwxrwsr-x 1 wagner m3 2068 2013-04-13 14:36 ./tutorial/m3/m3_27.html -rwxrwsr-x 1 wagner m3 1809 2013-04-13 14:36 ./tutorial/m3/m3_28.html -rwxrwsr-x 1 wagner m3 2698 2013-04-13 14:36 ./tutorial/m3/m3_29.html -rwxrwsr-x 1 wagner m3 1610 2013-04-13 14:36 ./tutorial/m3/m3_2.html -rwxrwsr-x 1 wagner m3 1261 2013-04-13 14:36 ./tutorial/m3/m3_30.html -rwxrwsr-x 1 wagner m3 1587 2013-04-13 14:36 ./tutorial/m3/m3_31.html -rwxrwsr-x 1 wagner m3 2271 2013-04-13 14:36 ./tutorial/m3/m3_32.html -rwxrwsr-x 1 wagner m3 1858 2013-04-13 14:36 ./tutorial/m3/m3_33.html -rwxrwsr-x 1 wagner m3 1665 2013-04-13 14:36 ./tutorial/m3/m3_34.html -rwxrwsr-x 1 wagner m3 2486 2013-04-13 14:36 ./tutorial/m3/m3_35.html -rwxrwsr-x 1 wagner m3 1389 2013-04-13 14:36 ./tutorial/m3/m3_36.html -rwxrwsr-x 1 wagner m3 1173 2013-04-13 14:36 ./tutorial/m3/m3_37.html -rwxrwsr-x 1 wagner m3 1600 2013-04-13 14:36 ./tutorial/m3/m3_38.html -rwxrwsr-x 1 wagner m3 1461 2013-04-13 14:36 ./tutorial/m3/m3_39.html -rwxrwsr-x 1 wagner m3 2051 2013-04-13 14:36 ./tutorial/m3/m3_3.html -rwxrwsr-x 1 wagner m3 1193 2013-04-13 14:36 ./tutorial/m3/m3_40.html -rwxrwsr-x 1 wagner m3 1719 2013-04-13 14:36 ./tutorial/m3/m3_41.html -rwxrwsr-x 1 wagner m3 1903 2013-04-13 14:36 ./tutorial/m3/m3_42.html -rwxrwsr-x 1 wagner m3 1530 2013-04-13 14:36 ./tutorial/m3/m3_43.html -rwxrwsr-x 1 wagner m3 1132 2013-04-13 14:36 ./tutorial/m3/m3_44.html -rwxrwsr-x 1 wagner m3 2410 2013-04-13 14:36 ./tutorial/m3/m3_45.html -rwxrwsr-x 1 wagner m3 1841 2013-04-13 14:36 ./tutorial/m3/m3_46.html -rwxrwsr-x 1 wagner m3 1575 2013-04-13 14:36 ./tutorial/m3/m3_47.html -rwxrwsr-x 1 wagner m3 3593 2013-04-13 14:36 ./tutorial/m3/m3_48.html -rwxrwsr-x 1 wagner m3 2928 2013-04-13 14:36 ./tutorial/m3/m3_49.html -rwxrwsr-x 1 wagner m3 1724 2013-04-13 14:36 ./tutorial/m3/m3_4.html -rwxrwsr-x 1 wagner m3 1766 2013-04-13 14:36 ./tutorial/m3/m3_50.html -rwxrwsr-x 1 wagner m3 2746 2013-04-13 14:36 ./tutorial/m3/m3_51.html -rwxrwsr-x 1 wagner m3 1558 2013-04-13 14:36 ./tutorial/m3/m3_52.html -rwxrwsr-x 1 wagner m3 1620 2013-04-13 14:36 ./tutorial/m3/m3_53.html -rwxrwsr-x 1 wagner m3 2907 2013-04-13 14:36 ./tutorial/m3/m3_54.html -rwxrwsr-x 1 wagner m3 1684 2013-04-13 14:36 ./tutorial/m3/m3_55.html -rwxrwsr-x 1 wagner m3 1812 2013-04-13 14:36 ./tutorial/m3/m3_56.html -rwxrwsr-x 1 wagner m3 1451 2013-04-13 14:36 ./tutorial/m3/m3_57.html -rwxrwsr-x 1 wagner m3 1126 2013-04-13 14:36 ./tutorial/m3/m3_58.html -rwxrwsr-x 1 wagner m3 1415 2013-04-13 14:36 ./tutorial/m3/m3_59.html -rwxrwsr-x 1 wagner m3 3899 2013-04-13 14:36 ./tutorial/m3/m3_5.html -rwxrwsr-x 1 wagner m3 2402 2013-04-13 14:36 ./tutorial/m3/m3_60.html -rwxrwsr-x 1 wagner m3 2352 2013-04-13 14:36 ./tutorial/m3/m3_61.html -rwxrwsr-x 1 wagner m3 1365 2013-04-13 14:36 ./tutorial/m3/m3_62.html -rwxrwsr-x 1 wagner m3 1265 2013-04-13 14:36 ./tutorial/m3/m3_63.html -rwxrwsr-x 1 wagner m3 1309 2013-04-13 14:36 ./tutorial/m3/m3_64.html -rwxrwsr-x 1 wagner m3 3073 2013-04-13 14:36 ./tutorial/m3/m3_65.html -rwxrwsr-x 1 wagner m3 3531 2013-04-13 14:36 ./tutorial/m3/m3_66.html -rwxrwsr-x 1 wagner m3 2757 2013-04-13 14:36 ./tutorial/m3/m3_67.html -rwxrwsr-x 1 wagner m3 2660 2013-04-13 14:36 ./tutorial/m3/m3_68.html -rwxrwsr-x 1 wagner m3 2392 2013-04-13 14:36 ./tutorial/m3/m3_69.html -rwxrwsr-x 1 wagner m3 3239 2013-04-13 14:36 ./tutorial/m3/m3_6.html -rwxrwsr-x 1 wagner m3 2165 2013-04-13 14:36 ./tutorial/m3/m3_70.html -rwxrwsr-x 1 wagner m3 1233 2013-04-13 14:36 ./tutorial/m3/m3_71.html -rwxrwsr-x 1 wagner m3 1931 2013-04-13 14:36 ./tutorial/m3/m3_72.html -rwxrwsr-x 1 wagner m3 1453 2013-04-13 14:36 ./tutorial/m3/m3_73.html -rwxrwsr-x 1 wagner m3 2133 2013-04-13 14:36 ./tutorial/m3/m3_74.html -rwxrwsr-x 1 wagner m3 1721 2013-04-13 14:36 ./tutorial/m3/m3_75.html -rwxrwsr-x 1 wagner m3 3972 2013-04-13 14:36 ./tutorial/m3/m3_76.html -rwxrwsr-x 1 wagner m3 5170 2013-04-13 14:36 ./tutorial/m3/m3_77.html -rwxrwsr-x 1 wagner m3 1640 2013-04-13 14:36 ./tutorial/m3/m3_78.html -rwxrwsr-x 1 wagner m3 3608 2013-04-13 14:36 ./tutorial/m3/m3_79.html -rwxrwsr-x 1 wagner m3 1352 2013-04-13 14:36 ./tutorial/m3/m3_7.html -rwxrwsr-x 1 wagner m3 1176 2013-04-13 14:36 ./tutorial/m3/m3_80.html -rwxrwsr-x 1 wagner m3 1390 2013-04-13 14:36 ./tutorial/m3/m3_81.html -rwxrwsr-x 1 wagner m3 1319 2013-04-13 14:36 ./tutorial/m3/m3_82.html -rwxrwsr-x 1 wagner m3 3127 2013-04-13 14:36 ./tutorial/m3/m3_83.html -rwxrwsr-x 1 wagner m3 1932 2013-04-13 14:36 ./tutorial/m3/m3_8.html -rwxrwsr-x 1 wagner m3 2028 2013-04-13 14:36 ./tutorial/m3/m3_9.html -rwxrwsr-x 1 wagner m3 39575 2013-04-13 14:36 ./tutorial/m3/m3_toc.html -rwxrwsr-x 1 wagner m3 37257 2013-04-13 14:36 ./tutorial/m3/old-index.html drwxrwsr-x 33 root m3 4096 2013-04-13 14:36 ./tutorial/ui drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/browser -rwxrwsr-x 1 wagner m3 2995 2013-04-13 14:36 ./tutorial/ui/browser/tut-browser.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/checkbox -rwxrwsr-x 1 wagner m3 2623 2013-04-13 14:36 ./tutorial/ui/checkbox/tut-checkbox.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/common -rwxrwsr-x 1 wagner m3 1658 2013-04-13 14:36 ./tutorial/ui/common/tut-common.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/confirm -rwxrwsr-x 1 wagner m3 600 2013-04-13 14:36 ./tutorial/ui/confirm/ConfirmVBT.i3 -rwxrwsr-x 1 wagner m3 1514 2013-04-13 14:36 ./tutorial/ui/confirm/ConfirmVBT.m3 -rwxrwsr-x 1 wagner m3 2751 2013-04-13 14:36 ./tutorial/ui/confirm/tut-confirm.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/cross -rwxrwsr-x 1 wagner m3 26685 2013-04-13 14:36 ./tutorial/ui/cross/tut-cross.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/drag -rwxrwsr-x 1 wagner m3 2052 2013-04-13 14:36 ./tutorial/ui/drag/tut-drag.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/draw -rwxrwsr-x 1 wagner m3 2620 2013-04-13 14:36 ./tutorial/ui/draw/tut-draw.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/edit -rwxrwsr-x 1 wagner m3 2441 2013-04-13 14:36 ./tutorial/ui/edit/tut-edit.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/feedback -r-xrwsr-x 1 wagner m3 487 2013-04-13 14:36 ./tutorial/ui/feedback/feedback1.gif -r-xrwsr-x 1 wagner m3 487 2013-04-13 14:36 ./tutorial/ui/feedback/feedback2.gif -r-xrwsr-x 1 wagner m3 598 2013-04-13 14:36 ./tutorial/ui/feedback/feedback3.gif -rwxrwsr-x 1 wagner m3 2175 2013-04-13 14:36 ./tutorial/ui/feedback/tut-feedback.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/hello -rwxrwsr-x 1 wagner m3 2515 2013-04-13 14:36 ./tutorial/ui/hello/tut-hello.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/intro -rwxrwsr-x 1 wagner m3 2319 2013-04-13 14:36 ./tutorial/ui/intro/tut-intro.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/key -rwxrwsr-x 1 wagner m3 2689 2013-04-13 14:36 ./tutorial/ui/key/tut-key.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/list -rwxrwsr-x 1 wagner m3 3206 2013-04-13 14:36 ./tutorial/ui/list/tut-list.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/menu1 -rwxrwsr-x 1 wagner m3 3285 2013-04-13 14:36 ./tutorial/ui/menu1/tut-menu1.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/menu2 -rwxrwsr-x 1 wagner m3 2540 2013-04-13 14:36 ./tutorial/ui/menu2/tut-menu2.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/mouse -rwxrwsr-x 1 wagner m3 1296 2013-04-13 14:36 ./tutorial/ui/mouse/Event.m3-sep -rwxrwsr-x 1 wagner m3 1922 2013-04-13 14:36 ./tutorial/ui/mouse/Mouse.m3-elided -rwxrwsr-x 1 wagner m3 2975 2013-04-13 14:36 ./tutorial/ui/mouse/tut-mouse.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/numeric -rwxrwsr-x 1 wagner m3 3157 2013-04-13 14:36 ./tutorial/ui/numeric/tut-numeric.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/overlap -rwxrwsr-x 1 wagner m3 2437 2013-04-13 14:36 ./tutorial/ui/overlap/tut-overlap.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/overlay -rwxrwsr-x 1 wagner m3 2126 2013-04-13 14:36 ./tutorial/ui/overlay/tut-overlay.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/push -rwxrwsr-x 1 wagner m3 3235 2013-04-13 14:36 ./tutorial/ui/push/tut-push.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/radio -rwxrwsr-x 1 wagner m3 1716 2013-04-13 14:36 ./tutorial/ui/radio/RadioButtons.m3 -rwxrwsr-x 1 wagner m3 1898 2013-04-13 14:36 ./tutorial/ui/radio/tut-radio.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/react -rwxrwsr-x 1 wagner m3 2636 2013-04-13 14:36 ./tutorial/ui/react/tut-react.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/rubber -rwxrwsr-x 1 wagner m3 4110 2013-04-13 14:36 ./tutorial/ui/rubber/tut-rubber.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/script -rwxrwsr-x 1 wagner m3 63 2013-04-13 14:36 ./tutorial/ui/script/m3makefile -rwxrwsr-x 1 wagner m3 1377 2013-04-13 14:36 ./tutorial/ui/script/tut-script.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/scroll -rwxrwsr-x 1 wagner m3 2516 2013-04-13 14:36 ./tutorial/ui/scroll/tut-scroll.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/shadow -rwxrwsr-x 1 wagner m3 2646 2013-04-13 14:36 ./tutorial/ui/shadow/tut-shadow.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/source -rwxrwsr-x 1 wagner m3 2374 2013-04-13 14:36 ./tutorial/ui/source/tut-source.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/switches -r-xrwsr-x 1 wagner m3 1370 2013-04-13 14:36 ./tutorial/ui/switches/switches1.gif -r-xrwsr-x 1 wagner m3 1385 2013-04-13 14:36 ./tutorial/ui/switches/switches2.gif -r-xrwsr-x 1 wagner m3 1553 2013-04-13 14:36 ./tutorial/ui/switches/switches3.gif -r-xrwsr-x 1 wagner m3 1601 2013-04-13 14:36 ./tutorial/ui/switches/switches4.gif -rwxrwsr-x 1 wagner m3 2821 2013-04-13 14:36 ./tutorial/ui/switches/tut-switches.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/text -rwxrwxr-x 1 wagner m3 3234 2013-04-13 14:36 ./tutorial/ui/text/tut-text.html -rwxrwsr-x 1 wagner m3 3199 2013-04-13 14:36 ./tutorial/ui/tutorial.html drwxrwsr-x 3 root m3 4096 2013-04-13 14:36 ./tutorial/ui/update -rwxrwsr-x 1 wagner m3 2604 2013-04-13 14:36 ./tutorial/ui/update/tut-update.html -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Sat Apr 13 17:48:09 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 13 Apr 2013 11:48:09 -0400 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: References: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Message-ID: <20130413154809.GB31583@topoi.pooq.com> On Sat, Apr 13, 2013 at 02:44:40AM +0000, Jay K wrote: > > Very old compilers don't support passing structs by value? THose would be very okd indeed. I know it wasn't available in the early 70's. But I don't think anyone is running Unix on a PDP-11 any more. I don't remember any more recent C compilers that don't pass strutures by value. Does anyone else? > > Third question that has been bugging me. > The C backend can output #line directives. > So you step through the Modula-3 source. What people expect. > This was working, and probably still does. > I turned it off subject to a constant in the backend. > Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) > > This is great for, during backend development/debugging, the C compiler gives me C line numbers. > If the backend worked perfectly, this would be pointless. > I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. > There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. > > > What to do to cater to both/everyone? > I wish I could have multiple #line directives: > #line 123 foo.m3.c 456 foo.m3 > > > but that doesn't exit. > I could encode information in the file name: > #line 123 "foo.m3.c/456 foo.m3" > > > but that is imperfect; error messages will be good, but debugging won't work > > > I could leave it as an #ifdef in the code. > I do not believe the following works: > #ifndef CLINE > #define LINE(cline, cfile, m3line, m3file) cline cfile > #else > #define LINE(cline, cfile, m3line, m3file) m3line m3file > #endif > #line LINE(123, "foo.c", 456, "foo.m3") > > > but I'll try it. > > > I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: > #ifndef CLINE > #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) > #endif > > This is bloated, but might be best. > > > if "#define LINE" works, great, but I doubt it will. If it works, it's likely to fail on C compilers that are a lot younger than PDP-11 Unix. But it's a lovely idea. > > > --- typeindex besides typeid? --- > > > I'm now doing a lot of lookups of typeids. > It'd be super nice if the frontend also maintained "small" incrementing > typeIndices that I could use to index into an array. > > > set_type_count(typeCount:CARDINAL); (* maybe *) > declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); That would need the front end to know how many types there would be before it can generate the typeCount. But if the typeCount were to be considered an estimate, or not available at all, the back end could reaallocate the typeindex-indexed array when necessary (or use some array-of-arrays data structure for growing arrays, to reduce copying on reallocation). You'd get almost the same performance, and obviate placinng a constraint on all future front-ends. (Yes, I'm still dreaming of a GPL2-compatible front end someday). > > > and thereafter, use typeIndex instead of typeId, an index into an array. > From hendrik at topoi.pooq.com Sat Apr 13 17:52:01 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 13 Apr 2013 11:52:01 -0400 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: References: <516825ED.9010003@lcwb.coop> Message-ID: <20130413155201.GC31583@topoi.pooq.com> On Sat, Apr 13, 2013 at 08:52:28AM +0200, Dragi?a Duri? wrote: > Never ending story :). > > To make it short - let's move to git! :) I do wish Linus hadn't rejected monotone. I find it much easier to use. > On Apr 12, 2013, at 5:33 PM, Jay K wrote: > > > CVS is awful. Even svn is now considered obsolete, let alone cvs. -- hendrik From rodney_bates at lcwb.coop Sun Apr 14 17:18:15 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 14 Apr 2013 10:18:15 -0500 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: References: <516825ED.9010003@lcwb.coop> Message-ID: <516AC8B7.2030807@lcwb.coop> Thanks. This appears to have worked. On 04/12/2013 10:33 AM, Jay K wrote: > CVS is awful. > Try this: > make sure you have "everything" "backed up" esp. m3-defn-complete.pdf > rm -rf the local directory with m3-defn-complete.pdf (that you backed up) > cvs upd -dAP to get it back > if m3-defn-complete.pdf is there > { > rm m3-defn-complete.pdf > cvs delete m3-defn-complete.pdf > cvs commit m3-defn-complete.pdf > } > copy in your new m3-defn-complete.pdf > cvs add m3-defn-complete.pdf > cvs commit m3-defn-complete.pdf > > - Jay > > > > > Date: Fri, 12 Apr 2013 10:19:09 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: [M3devel] Another CVS problem: adding a new file > > > > m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. > > cvs checkout says: > > > > cvs server: cannot find module `m3-defn-complete.pdf' - ignored > > > > When I try to add it, cvs add says: > > > > cvs add: `m3-defn-complete.pdf' added independently by second party > > > > and when I try to commit, cvs says: > > > > cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' > > cvs [commit aborted]: correct above errors first! > > From dragisha at m3w.org Mon Apr 15 09:22:29 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 15 Apr 2013 09:22:29 +0200 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <20130413155201.GC31583@topoi.pooq.com> References: <516825ED.9010003@lcwb.coop> <20130413155201.GC31583@topoi.pooq.com> Message-ID: <5C4A22D4-1CCA-4B67-86B1-E120721875A8@m3w.org> As we are witnessess in this thread, every system has its quirks, and there is no system without need-to-learn. So does cvs, and svn and git? But they are all alive and kicking, and monotone looks like it is not. So, git for cm3 it is? :) On Apr 13, 2013, at 5:52 PM, Hendrik Boom wrote: > I do wish Linus hadn't rejected monotone. I find it much easier to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Apr 15 09:30:29 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 15 Apr 2013 09:30:29 +0200 Subject: [M3devel] cvsup client, lots of SetAttrs and slow shutdown Message-ID: <886D7CC9-6ACE-48B6-8EF2-193D1EDE44A0@m3w.org> ? SetAttrs cm3/caltech-parser/term/src/Term.i3,v SetAttrs cm3/caltech-parser/term/src/Term.m3,v SetAttrs cm3/caltech-parser/term/src/TermC.c,v SetAttrs cm3/caltech-parser/term/src/TermC.h,v SetAttrs cm3/caltech-parser/term/src/TermC.i3,v SetAttrs cm3/caltech-parser/term/src/TermIO.i3,v SetAttrs cm3/caltech-parser/term/src/TermIO.m3,v SetAttrs cm3/caltech-parser/term/src/Termios.c,v ? Shutting down connection to server ?and waitinggggg Why does this happen? TIA, dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Tue Apr 16 03:28:16 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: <20130416012125.2CB685DEB25@birch.elegosoft.com> References: <20130416012125.2CB685DEB25@birch.elegosoft.com> Message-ID: It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 09:29:48 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 09:29:48 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) Message-ID: <3120B9A9-6804-4F51-83F7-B4F7DF0B9756@m3w.org> At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rcolebur at SCIRES.COM Tue Apr 16 18:34:45 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 16 Apr 2013 16:34:45 +0000 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Dragi?a : I notice that your tar.gz contains 4 files whose name differs only by case of letters: 1. libevent/src/BufferEvent.i3 2. libevent/src/BufferEvent.m3 3. libevent/src/bufferevent.i3 4. libevent/src/bufferevent.m3 On computers where the case of filenames is not significant, 2 of these files will be lost. This is the case on Windows. --Randy Coleburn From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Tuesday, April 16, 2013 3:30 AM To: m3devel Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 16 18:48:05 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 16 Apr 2013 16:48:05 +0000 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Yes and no.Agreed one must avoid these constructs, file names that differ only in case. It is filesystems not operating systems that are generally case sensitive or case insensitive, though it is even more complicated than that. Consider networked file systems.All of ext3, HFS+, NTFS, FAT, and more are usable on Windows, MacOSX, and Linux/Unix. I believe ext3 is always case sensitive, FAT is always case insensitive, HFS+ I think it is an option at format time, and NTFS gets passed a flag as to case sensitivity for every file open call (and the upcase table is stored on disk at format time, in order to be stable for the entire life of the volume independent of what version of what operating system is operating on it) (er..the flag is by virtue of the NT kernel, so many file systems get the flag, but I assume some ignore it, and NTFS can be used on Linux and MacOSX and I don't know if such a flag exists there.) - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 16:34:45 +0000 Subject: Re: [M3devel] m3 libevent binding + objectification, pre-pre-release :) Dragi?a : I notice that your tar.gz contains 4 files whose name differs only by case of letters: 1. libevent/src/BufferEvent.i3 2. libevent/src/BufferEvent.m3 3. libevent/src/bufferevent.i3 4. libevent/src/bufferevent.m3 On computers where the case of filenames is not significant, 2 of these files will be lost. This is the case on Windows. --Randy Coleburn From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Tuesday, April 16, 2013 3:30 AM To: m3devel Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 19:01:51 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 19:01:51 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Thanks, I will fix it and resend. On Apr 16, 2013, at 6:34 PM, Coleburn, Randy wrote: > Dragi?a : > > I notice that your tar.gz contains 4 files whose name differs only by case of letters: > 1. libevent/src/BufferEvent.i3 > 2. libevent/src/BufferEvent.m3 > 3. libevent/src/bufferevent.i3 > 4. libevent/src/bufferevent.m3 > > On computers where the case of filenames is not significant, 2 of these files will be lost. > This is the case on Windows. > > --Randy Coleburn > > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Tuesday, April 16, 2013 3:30 AM > To: m3devel > Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) > > At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. > > I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). > -- > Dragi?a Duri? > dragisha at m3w.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 19:04:35 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 19:04:35 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <11121DBF-4C43-43AA-8574-DD40D15E8916@m3w.org> There is also a case of Dropbox? It is case insensitive. On Apr 16, 2013, at 6:48 PM, Jay K wrote: > Consider networked file systems. > All of ext3, HFS+, NTFS, FAT, and more are usable on Windows, MacOSX, and Linux/Unix. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 16 19:16:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 16 Apr 2013 19:16:28 +0200 Subject: [M3devel] m3 libevent binding + objectification, pre-pre-release :) In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: -- Dragi?a Duri? dragisha at m3w.org https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11743.tar.gz Here it is. On Apr 16, 2013, at 7:01 PM, Dragi?a Duri? wrote: > Thanks, I will fix it and resend. > > On Apr 16, 2013, at 6:34 PM, Coleburn, Randy wrote: > >> Dragi?a : >> >> I notice that your tar.gz contains 4 files whose name differs only by case of letters: >> 1. libevent/src/BufferEvent.i3 >> 2. libevent/src/BufferEvent.m3 >> 3. libevent/src/bufferevent.i3 >> 4. libevent/src/bufferevent.m3 >> >> On computers where the case of filenames is not significant, 2 of these files will be lost. >> This is the case on Windows. >> >> --Randy Coleburn >> >> From: Dragi?a Duri? [mailto:dragisha at m3w.org] >> Sent: Tuesday, April 16, 2013 3:30 AM >> To: m3devel >> Subject: EXT:[M3devel] m3 libevent binding + objectification, pre-pre-release :) >> >> At https://dl.dropboxusercontent.com/u/60554338/m3-libevent-r11742.tar.gz is a library I made for a project of mine. It works, I tested it pretty thoroughly, on AMD64_LINUX. It compiles on AMD64_DARWIN, although I did not test it there. Uses libevent2. >> >> I do not have a time for legalese, if there is a question about licensing, it is cm3-alike. I would like to know if it's used/useful, but I give no warranty of any kind, and so on :). >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torsten.kirschner at gmail.com Tue Apr 16 07:32:15 2013 From: torsten.kirschner at gmail.com (Torsten Kirschner) Date: Tue, 16 Apr 2013 07:32:15 +0200 Subject: [M3devel] new release In-Reply-To: <20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL> <00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu> <51126B00.7010301@columbus.rr.com> <20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> Message-ID: On Wed, Feb 6, 2013 at 4:38 PM, Olaf Wagner wrote: > ... > > Well, I think we will do a new release as soon as the C backend has > settled. > But you can always get current snapshots of the system from the Hudson > builds, at least for Linux and FreeBSD, see > > http://www.opencm3.net/snaps/snapshot-index.html > > I am amazed to see that SOLsun for Solaris 2.10 is a target. However, http://www.opencm3.net/snaps/cm3-bin-core-SOLsun-d5.9.0-sparc-sun-solaris2.10-2013-04-16-01-56-00.tgzseems to be the only link on that page that does not work. Coincidence, or is it part of a larger plan? ;-) best regards T -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Tue Apr 16 21:42:40 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Tue, 16 Apr 2013 21:42:40 +0200 Subject: [M3devel] new release In-Reply-To: References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL><00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu><51126B00.7010301@columbus.rr.com><20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com> Message-ID: ...at least for Linux and FreeBSD,... and for Windows nobody cares even a bit! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 04:37:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 02:37:15 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, Message-ID: Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 04:32:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, Message-ID: Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 04:47:47 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 02:47:47 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, , , Message-ID: In the frontend, when pop_struct is called, is that too late to declare_record? To compile the type, is it? #0 M3CG_MultiPass__pop_struct (self_L_1033=0x101551758 "", m3_typeid_L_1034=1557134085, byte_size_L_1035=8, alignment_L_1036=8) at M3CG_MultiPass.m3.c:38639 #1 0x000000010044718a in M3CG_Check__pop_struct (self_L_369=0x1015525b8, t_L_370=1557134085, s_L_371=8, a_L_372=8) at M3CG_Check.m3.c:34613 #2 0x000000010024a584 in CG__Pop_struct (t_L_578=1557134085, s_L_579=64, a_L_580=64) at CG.m3.c:83537 #3 0x00000001002ddcd7 in Formal__EmitArg (proc_L_215=0x10151e4c8 "??h", formal_L_216=0x10151c7a0 "?Bj", actual_L_217=0x10151c758 "??h") at Formal.m3.c:15818 #4 0x00000001002c3aa7 in UserProc (ce_L_148=0x10151e540 "@\034\020\001\001") at UserProc.m3.c:5026 #5 0x000000010019b893 in CallExpr (p_L_149=0x10151e540 "@\034\020\001\001") at CallExpr.m3.c:12276 #6 0x0000000100186765 in Expr (t_L_126=0x10151e540 "@\034\020\001\001") at Expr.m3.c:4085 #7 0x000000010025a70f in CallStmt__Compile (p_L_36=0x10151e598) at CallStmt.m3.c:1411 #8 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e598 "??i") at Stmt.m3.c:2881 #9 0x0000000100259e79 in BlockStmt__Compile (p_L_69=0x10151e320) at BlockStmt.m3.c:4642 #10 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e320 "?i") at Stmt.m3.c:2881 #11 0x00000001002f35b5 in Procedure__GenBody (p_L_318=0x10151e0b0 "?`j") at Procedure.m3.c:21223 #12 0x00000001002f38ec in Procedure__EmitBody (x_L_310=0x10151e268) at Procedure.m3.c:19937 #13 0x00000001002275b3 in ProcBody__EmitBody (t_L_64=0x10151e268 "?\030\020\001\001") at ProcBody.m3.c:6940 #14 0x000000010022794d in ProcBody__EmitAll (proc_info_L_56=0x7fff5fbfdeb8) at ProcBody.m3.c:2822 #15 0x00000001002e73d6 in Module__CompileModule (t_L_379=0x101512fe0 "?Xj") at Module.m3.c:25364 #16 0x00000001002eafe8 in Module__Compile (t_L_283=0x101512fe0 "?Xj") at Module.m3.c:23264 #17 0x00000001001f78df in M3Front__DoCompile () at M3Front.m3.c:7176 #18 0x00000001001f8391 in M3Front__Compile (input_L_88=0x7fff5fbfe150, env_L_89=0x1013910a8, options_L_90=0x101355840) at M3Front.m3.c:3827 #19 0x0000000100021886 in Builder__RunM3 (s_L_494=0x10136fdb0, u_L_495=0x1012df768, object_L_496=0x1013557a0 "??n") at Builder.m3.c:56168 #20 0x0000000100022bac in Builder__PushOneM3 (s_L_444=0x10136fdb0, u_L_445=0x1012df768) at Builder.m3.c:48299 #21 0x0000000100023cb5 in Builder__CompileM3 (s_L_423=0x10136fdb0, u_L_424=0x1012df768) at Builder.m3.c:45901 #22 0x000000010001ea71 in Builder__CompileOne (s_L_404=0x10136fdb0, u_L_405=0x1012df768) at Builder.m3.c - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: Re: [M3devel] frontend misses a few types Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 17 11:26:55 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 17 Apr 2013 11:26:55 +0200 Subject: [M3devel] cm3ide (/ m3browser?) references Message-ID: cm3ide does not parse procedure bodies for references, only signature elements are parsed/hyperlinked. Is there a way to get internal references parsed/hyperlinked - short of do-it-with-m3tk? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Wed Apr 17 18:06:11 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 16:06:11 +0000 Subject: [M3devel] cm3ide (/ m3browser?) references In-Reply-To: References: Message-ID: 1) I don't know. but 2) cm3ide I believe is consuming frontend output. jbook2:python jay$ ls /dev2/cm3/m3-sys/m3front/src/*/*Web* /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.i3 /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.m3 Likely nobody would object if you augmented this with more information. It looks like it is structured like putting in another backend, but one that doesn't get all the calls i.e. codegen like load/store/add/call. book2:python jay$ grep -i webinfo /dev2/cm3/m3-sys/m3front/src/*/*m3 /dev2/cm3/m3-sys/m3front/src/misc/CG.m3:IMPORT Scanner, Error, Module, RunTyme, WebInfo; /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Import_unit (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Export_unit (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_array (t, index, elt, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_open_array (t, elt, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_enum (t, n_elts, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_enum_elt (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_packed (t, s, base); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_record (t, s, n_fields); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_field (n, o, s, t); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_set (t, domain, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_subrange (t, domain, min, max, s); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_pointer (t, target, brand, traced); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_indirect (x, target); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_proctype (t, n_formals, result, n_raises); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_formal (n, t); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_raises (n); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_object (t, super, brand, traced, /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_method (n, signature, dfault); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_override (n, dfault); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Declare_opaque (t, super); /dev2/cm3/m3-sys/m3front/src/misc/CG.m3: WebInfo.Reveal_opaque (lhs, rhs); /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.m3:MODULE WebInfo; /dev2/cm3/m3-sys/m3front/src/misc/WebInfo.m3:END WebInfo. /dev2/cm3/m3-sys/m3front/src/values/Module.m3:IMPORT Host, Token, Revelation, Coverage, Decl, Scanner, WebInfo; /dev2/cm3/m3-sys/m3front/src/values/Module.m3: WebInfo.Reset (); /dev2/cm3/m3-sys/m3front/src/values/Module.m3: Host.env.note_webinfo (WebInfo.Finish ()); /dev2/cm3/m3-sys/m3front/src/values/Tipe.m3:IMPORT M3, M3ID, CG, Value, ValueRep, Scope, OpaqueType, WebInfo; /dev2/cm3/m3-sys/m3front/src/values/Tipe.m3: WebInfo.Declare_typename (uid, t); I kind of wonder if it could be better structured by actually taking it out of m3front and layering like I have my multiple pass backend.. i.e. a multiplexing backend.. - Jay From: dragisha at m3w.org Date: Wed, 17 Apr 2013 11:26:55 +0200 To: m3devel at elegosoft.com Subject: [M3devel] cm3ide (/ m3browser?) references cm3ide does not parse procedure bodies for references, only signature elements are parsed/hyperlinked. Is there a way to get internal references parsed/hyperlinked - short of do-it-with-m3tk? --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 17 18:24:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Apr 2013 16:24:51 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, , , , , , Message-ID: ok, so this fixes it. I still have to build everything to verify. But which of the two lines is right? Both? And what about the comment about the assert? And what about other types like fixed size arrays? I'll try them. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/values/Formal.m3,v retrieving revision 1.18 diff -u -r1.18 Formal.m3 --- Formal.m3 26 Sep 2012 17:12:37 -0000 1.18 +++ Formal.m3 17 Apr 2013 16:23:29 -0000 @@ -600,6 +600,8 @@ PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) + Type.Compile (t.tipe); + Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) Type.Compile (t.tipe); Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); | Mode.mVAR => Expr.CompileAddress (actual, traced := TRUE); | Mode.mCONST => IF Expr.IsDesignator (actual) THEN Expr.CompileAddress (actual, traced := FALSE); ELSE Expr.Compile (actual); (* not needed because of the ASSERT above: GenCopy (t.tipe); *) END; END; END GenRecord; From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:47:47 +0000 Subject: Re: [M3devel] frontend misses a few types In the frontend, when pop_struct is called, is that too late to declare_record? To compile the type, is it? #0 M3CG_MultiPass__pop_struct (self_L_1033=0x101551758 "", m3_typeid_L_1034=1557134085, byte_size_L_1035=8, alignment_L_1036=8) at M3CG_MultiPass.m3.c:38639 #1 0x000000010044718a in M3CG_Check__pop_struct (self_L_369=0x1015525b8, t_L_370=1557134085, s_L_371=8, a_L_372=8) at M3CG_Check.m3.c:34613 #2 0x000000010024a584 in CG__Pop_struct (t_L_578=1557134085, s_L_579=64, a_L_580=64) at CG.m3.c:83537 #3 0x00000001002ddcd7 in Formal__EmitArg (proc_L_215=0x10151e4c8 "??h", formal_L_216=0x10151c7a0 "?Bj", actual_L_217=0x10151c758 "??h") at Formal.m3.c:15818 #4 0x00000001002c3aa7 in UserProc (ce_L_148=0x10151e540 "@\034\020\001\001") at UserProc.m3.c:5026 #5 0x000000010019b893 in CallExpr (p_L_149=0x10151e540 "@\034\020\001\001") at CallExpr.m3.c:12276 #6 0x0000000100186765 in Expr (t_L_126=0x10151e540 "@\034\020\001\001") at Expr.m3.c:4085 #7 0x000000010025a70f in CallStmt__Compile (p_L_36=0x10151e598) at CallStmt.m3.c:1411 #8 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e598 "??i") at Stmt.m3.c:2881 #9 0x0000000100259e79 in BlockStmt__Compile (p_L_69=0x10151e320) at BlockStmt.m3.c:4642 #10 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e320 "?i") at Stmt.m3.c:2881 #11 0x00000001002f35b5 in Procedure__GenBody (p_L_318=0x10151e0b0 "?`j") at Procedure.m3.c:21223 #12 0x00000001002f38ec in Procedure__EmitBody (x_L_310=0x10151e268) at Procedure.m3.c:19937 #13 0x00000001002275b3 in ProcBody__EmitBody (t_L_64=0x10151e268 "?\030\020\001\001") at ProcBody.m3.c:6940 #14 0x000000010022794d in ProcBody__EmitAll (proc_info_L_56=0x7fff5fbfdeb8) at ProcBody.m3.c:2822 #15 0x00000001002e73d6 in Module__CompileModule (t_L_379=0x101512fe0 "?Xj") at Module.m3.c:25364 #16 0x00000001002eafe8 in Module__Compile (t_L_283=0x101512fe0 "?Xj") at Module.m3.c:23264 #17 0x00000001001f78df in M3Front__DoCompile () at M3Front.m3.c:7176 #18 0x00000001001f8391 in M3Front__Compile (input_L_88=0x7fff5fbfe150, env_L_89=0x1013910a8, options_L_90=0x101355840) at M3Front.m3.c:3827 #19 0x0000000100021886 in Builder__RunM3 (s_L_494=0x10136fdb0, u_L_495=0x1012df768, object_L_496=0x1013557a0 "??n") at Builder.m3.c:56168 #20 0x0000000100022bac in Builder__PushOneM3 (s_L_444=0x10136fdb0, u_L_445=0x1012df768) at Builder.m3.c:48299 #21 0x0000000100023cb5 in Builder__CompileM3 (s_L_423=0x10136fdb0, u_L_424=0x1012df768) at Builder.m3.c:45901 #22 0x000000010001ea71 in Builder__CompileOne (s_L_404=0x10136fdb0, u_L_405=0x1012df768) at Builder.m3.c - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: Re: [M3devel] frontend misses a few types Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 17 20:01:11 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 17 Apr 2013 20:01:11 +0200 Subject: [M3devel] cm3ide (/ m3browser?) references In-Reply-To: References: Message-ID: <7FF88BD3-BBBA-4042-BC85-C7968365EC75@m3w.org> I am using WebInfo output for various RT info/layout data needed in program. But, .M3WEB does not contain token level information. Not even what can be seen in cm3ide. You are probably right on this, though? It would be easier to work through m3front, and decorate along the way. On Apr 17, 2013, at 6:06 PM, Jay K wrote: > 1) I don't know. > but > 2) cm3ide I believe is consuming frontend output. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Wed Apr 17 20:27:50 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 17 Apr 2013 18:27:50 +0000 Subject: [M3devel] cm3ide (/ m3browser?) references Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF0C28B793@ATLEX04-SRV.SCIRES.LOCAL> I suppose it would require someone modifying the code, perhaps incorporating elements of m3tk. The current cm3ide is basically a repackaged version of Critical Mass? Reactor, with changes to deal with removal of intellectual property rights belonging to Critical Mass, Inc. --Randy Coleburn From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Wednesday, April 17, 2013 5:27 AM To: m3devel Subject: EXT:[M3devel] cm3ide (/ m3browser?) references cm3ide does not parse procedure bodies for references, only signature elements are parsed/hyperlinked. Is there a way to get internal references parsed/hyperlinked - short of do-it-with-m3tk? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Apr 18 09:07:06 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 18 Apr 2013 09:07:06 +0200 Subject: [M3devel] cm3ide cpu usage Message-ID: <7B1D4CA8-5469-4095-BC7E-4B9902785198@m3w.org> It looks like cm3ide becomes very CPU hungry, after some time. It is probably an issue with not-detected EOF in TCP.T "channel" they use. Anybody else met this issue? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Fri Apr 19 06:24:19 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Apr 2013 04:24:19 +0000 Subject: [M3devel] frontend misses a few types In-Reply-To: References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,,, , , , , , , , Message-ID: Here is a smaller fix that fixes more cases, i.e. large sets and fixed sized arrays. Index: values/Formal.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/values/Formal.m3,v retrieving revision 1.18 diff -u -r1.18 Formal.m3 --- values/Formal.m3 26 Sep 2012 17:12:37 -0000 1.18 +++ values/Formal.m3 19 Apr 2013 04:19:55 -0000 @@ -470,6 +470,7 @@ CG.Pop_param (CG.Type.Addr) ELSIF (is_struct) THEN EVAL Type.CheckInfo (t.tipe, info); + Type.Compile (t.tipe); CG.Pop_struct (Type.GlobalUID (t.tipe), info.size, info.alignment); ELSE (* by-value scalar *) CG.Pop_param (Type.CGType (t.tipe, in_memory := TRUE)); - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 16:24:51 +0000 Subject: Re: [M3devel] frontend misses a few types ok, so this fixes it. I still have to build everything to verify. But which of the two lines is right? Both? And what about the comment about the assert? And what about other types like fixed size arrays? I'll try them. =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/values/Formal.m3,v retrieving revision 1.18 diff -u -r1.18 Formal.m3 --- Formal.m3 26 Sep 2012 17:12:37 -0000 1.18 +++ Formal.m3 17 Apr 2013 16:23:29 -0000 @@ -600,6 +600,8 @@ PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) + Type.Compile (t.tipe); + Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); PROCEDURE GenRecord (t: T; actual: Expr.T) = BEGIN (* <* ASSERT Type.IsEqual (t.tipe, Expr.TypeOf (actual), NIL) *> *) Type.Compile (t.tipe); Type.Compile (Expr.TypeOf (actual)); CASE t.mode OF | Mode.mVALUE => Expr.Compile (actual); | Mode.mVAR => Expr.CompileAddress (actual, traced := TRUE); | Mode.mCONST => IF Expr.IsDesignator (actual) THEN Expr.CompileAddress (actual, traced := FALSE); ELSE Expr.Compile (actual); (* not needed because of the ASSERT above: GenCopy (t.tipe); *) END; END; END GenRecord; From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:47:47 +0000 Subject: Re: [M3devel] frontend misses a few types In the frontend, when pop_struct is called, is that too late to declare_record? To compile the type, is it? #0 M3CG_MultiPass__pop_struct (self_L_1033=0x101551758 "", m3_typeid_L_1034=1557134085, byte_size_L_1035=8, alignment_L_1036=8) at M3CG_MultiPass.m3.c:38639 #1 0x000000010044718a in M3CG_Check__pop_struct (self_L_369=0x1015525b8, t_L_370=1557134085, s_L_371=8, a_L_372=8) at M3CG_Check.m3.c:34613 #2 0x000000010024a584 in CG__Pop_struct (t_L_578=1557134085, s_L_579=64, a_L_580=64) at CG.m3.c:83537 #3 0x00000001002ddcd7 in Formal__EmitArg (proc_L_215=0x10151e4c8 "??h", formal_L_216=0x10151c7a0 "?Bj", actual_L_217=0x10151c758 "??h") at Formal.m3.c:15818 #4 0x00000001002c3aa7 in UserProc (ce_L_148=0x10151e540 "@\034\020\001\001") at UserProc.m3.c:5026 #5 0x000000010019b893 in CallExpr (p_L_149=0x10151e540 "@\034\020\001\001") at CallExpr.m3.c:12276 #6 0x0000000100186765 in Expr (t_L_126=0x10151e540 "@\034\020\001\001") at Expr.m3.c:4085 #7 0x000000010025a70f in CallStmt__Compile (p_L_36=0x10151e598) at CallStmt.m3.c:1411 #8 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e598 "??i") at Stmt.m3.c:2881 #9 0x0000000100259e79 in BlockStmt__Compile (p_L_69=0x10151e320) at BlockStmt.m3.c:4642 #10 0x0000000100252d32 in Stmt__Compile (t_L_43=0x10151e320 "?i") at Stmt.m3.c:2881 #11 0x00000001002f35b5 in Procedure__GenBody (p_L_318=0x10151e0b0 "?`j") at Procedure.m3.c:21223 #12 0x00000001002f38ec in Procedure__EmitBody (x_L_310=0x10151e268) at Procedure.m3.c:19937 #13 0x00000001002275b3 in ProcBody__EmitBody (t_L_64=0x10151e268 "?\030\020\001\001") at ProcBody.m3.c:6940 #14 0x000000010022794d in ProcBody__EmitAll (proc_info_L_56=0x7fff5fbfdeb8) at ProcBody.m3.c:2822 #15 0x00000001002e73d6 in Module__CompileModule (t_L_379=0x101512fe0 "?Xj") at Module.m3.c:25364 #16 0x00000001002eafe8 in Module__Compile (t_L_283=0x101512fe0 "?Xj") at Module.m3.c:23264 #17 0x00000001001f78df in M3Front__DoCompile () at M3Front.m3.c:7176 #18 0x00000001001f8391 in M3Front__Compile (input_L_88=0x7fff5fbfe150, env_L_89=0x1013910a8, options_L_90=0x101355840) at M3Front.m3.c:3827 #19 0x0000000100021886 in Builder__RunM3 (s_L_494=0x10136fdb0, u_L_495=0x1012df768, object_L_496=0x1013557a0 "??n") at Builder.m3.c:56168 #20 0x0000000100022bac in Builder__PushOneM3 (s_L_444=0x10136fdb0, u_L_445=0x1012df768) at Builder.m3.c:48299 #21 0x0000000100023cb5 in Builder__CompileM3 (s_L_423=0x10136fdb0, u_L_424=0x1012df768) at Builder.m3.c:45901 #22 0x000000010001ea71 in Builder__CompileOne (s_L_404=0x10136fdb0, u_L_405=0x1012df768) at Builder.m3.c - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 17 Apr 2013 02:32:15 +0000 Subject: Re: [M3devel] frontend misses a few types Here is what it looks like: INTERFACE VBT; TYPE VBT_T = OBJECT METHODS init(op: PaintOp_T := PaintOp_TransparentSwap; txt: Pixmap_T := Pixmap_Gray; READONLY delta := Point_T{0}); END; TYPE Pixmap_T = RECORD Pixmap_T_field: INTEGER END; CONST Pixmap_Gray = Pixmap_T{1}; TYPE PaintOp_T = RECORD PaintOp_T_field:INTEGER END; CONST PaintOp_Swap = PaintOp_T{2}; CONST PaintOp_TransparentSwap = PaintOp_T{3}; TYPE Point_T = RECORD Point_T_field: INTEGER END; END VBT. INTERFACE HighlightVBT; IMPORT VBT; TYPE HighlightVBT_T <: VBT.VBT_T; END HighlightVBT. MODULE Main; IMPORT HighlightVBT; PROCEDURE Main() = BEGIN NEW(HighlightVBT.HighlightVBT_T).init(); NEW(HighlightVBT.HighlightVBT_T).init(); END Main; BEGIN Main(); END Main. unit Main does not receive declare_record for PaintOp_T Pixmap_T and maybe Point_T It is somewhat obvious why. VBT is not directly imported by Main. Point_T is passed by reference, so the backend can inject a simple forward declaration: struct T123; typedef struct T123 T123; But PaintOp_T and Pixmap_T are passed by value and it is desirable to have them fully defined, so I can use C's pass by struct by value feature. Furthermore, multiple calls to init() generate multiple instances of Point_T{0}. Anyone interested in fixing it? I'll debug it probably.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 16 Apr 2013 01:28:16 +0000 Subject: [M3devel] frontend misses a few types It'd be great to fix this in the frontend. jbook2:p255 jay$ rm -rf AMD64_DARWIN && /dev2/cm3/m3-sys/cm3/AMD64_DARWIN/cm3 -keep --- building in AMD64_DARWIN --- ReadWish /cm3/pkg/libm3/AMD64_DARWIN/libm3.a ffffffffe90634a6 new source -> compiling VBT.i3 new source -> compiling HighlightVBT.i3 new source -> compiling HighlightVBT.m3 new source -> compiling Main.m3 warning: pop_struct: unknown typeid:T79A5AEBB warning: pop_struct: unknown typeid:T23E73F69 -> linking pgm ./pgm >stdout.pgm.raw 2>stderr.pgm.raw jbook2:p255 jay$ pwd /dev2/cm3/m3-sys/m3tests/src/p2/p255 Also, in this example, each call creates another copy of the default parameter in the module globals. That should be optimized in the frontend. The test case here is really small. - Jay > Date: Tue, 16 Apr 2013 03:21:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 13/04/16 03:21:25 > > Added files: > cm3/m3-sys/m3tests/src/p2/p255/: HighlightVBT.i3 HighlightVBT.m3 > Main.m3 VBT.i3 m3makefile > > Log message: > This test case demonstrates a problem > where the frontend doesn't describe all the types > to the backend. And also where it doesn't single-instance > constants that it could/should. > > It is adapted from Trestle and a little of libm3. > It is reduced very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 20 12:52:58 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 20 Apr 2013 12:52:58 +0200 Subject: [M3devel] "fork" Message-ID: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. My idea is basically to do this migration/fork without actually doing one. In short: * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. * Do all our work on SVN, * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. We can also use GIT in one of two scenarios: * Go straight from CVS to GIT, never look back; * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. Thanks for reading this! :) dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dragisha at m3w.org Sat Apr 20 14:15:56 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 20 Apr 2013 14:15:56 +0200 Subject: [M3devel] first tests, cvs2svn Message-ID: I did initial conversion, just to try it and see what happens. Initial size (CVS repo is: cca 2.1GB, Resulting size is: 661MB, tmp space used: under 600MB time used (on a core duo 2.4GHz box): as per table attached I had two collisions from Attic files, deleted them. Another problem was encoding ambiguity, solved it with additional switches. I am currently checking all of it out, and then I will compare it with a CVS full checkout. More on this in next post. dd ========================================== Command line: % cvs2svn -s ~/cm3-svn /opt/cm3-cvs --encoding=utf8 --fallback-encoding=latin1 Results: cvs2svn Statistics: ------------------ Total CVS Files: 57642 Total CVS Revisions: 159237 Total CVS Branches: 135634 Total CVS Tags: 1123784 Total Unique Tags: 963 Total Unique Branches: 16 CVS Repos Size in KB: 2069996 Total SVN Commits: 12228 First Revision Date: Sat Jan 13 15:15:12 2001 Last Revision Date: Thu Apr 18 18:24:28 2013 ------------------ Timings (seconds): ------------------ 292 pass1 CollectRevsPass 1 pass2 CleanMetadataPass 0 pass3 CollateSymbolsPass 514 pass4 FilterSymbolsPass 2 pass5 SortRevisionsPass 7 pass6 SortSymbolsPass 134 pass7 InitializeChangesetsPass 32 pass8 BreakRevisionChangesetCyclesPass 27 pass9 RevisionTopologicalSortPass 77 pass10 BreakSymbolChangesetCyclesPass 114 pass11 BreakAllChangesetCyclesPass 91 pass12 TopologicalSortPass 80 pass13 CreateRevsPass 22 pass14 SortSymbolOpeningsClosingsPass 4 pass15 IndexSymbolsPass 2050 pass16 OutputPass 3448 total -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hendrik at topoi.pooq.com Sat Apr 20 14:43:21 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 20 Apr 2013 08:43:21 -0400 Subject: [M3devel] "fork" In-Reply-To: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> Message-ID: <20130420124321.GA7844@topoi.pooq.com> On Sat, Apr 20, 2013 at 12:52:58PM +0200, Dragi?a Duri? wrote: > We have this situation where Elego does not have neither interest nor > resources to spare to do version control system migration. Projects > like GCC and GNOME have abandoned CVS for good, and they are only two > on a very long list. The main problem I see with this is that svn is still not a distributed version-control system. However, cvs2svn does seem to be a stepping-stone to most current distributed version-control systems, so it is a step in the right direction. -- hendrik From darko at darko.org Sat Apr 20 13:51:25 2013 From: darko at darko.org (Darko) Date: Sat, 20 Apr 2013 04:51:25 -0700 Subject: [M3devel] "fork" In-Reply-To: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> Message-ID: FWIW, I vote for a one way trip to GIT, to me it seems like far and away the best tool, probably because it is a clean break from CVS. Maybe we can host on GitHub or a similar service. Why do we need to maintain the existing CVS? I'm happy to donate a server if we need to move the build infrastructure as a result. On Apr 20, 2013, at 3:52 AM, Dragi?a Duri? wrote: > We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. > > My idea is basically to do this migration/fork without actually doing one. In short: > * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. > * Do all our work on SVN, > * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. > > This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. > > My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. > > We can also use GIT in one of two scenarios: > * Go straight from CVS to GIT, never look back; > * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. > > This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. > > I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. > > Thanks for reading this! :) > dd > > -- > Dragi?a Duri? > dragisha at m3w.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 20 19:52:52 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Apr 2013 17:52:52 +0000 Subject: [M3devel] struct pass and return, an additional mode? Message-ID: The frontend supports the following, Target.i3: results_on_left => when the front-end is passing structures the return result is the left-most parameter. Otherwise, it is the right-most parameter. standard_structs => TRUE => the front-end will take care of all structure passing: by VALUE parameters: callers pass the address of the structure and the callee copies it into a temporary. return results: the caller passes as the left-most or right-most parameter the address of the temporary that will hold the result and the callee copies the value there. FALSE => by VALUE parameters: the back-end is responsible. (ie. M3CG.T.Pop_struct will be called) return results: the caller passes as the left-most or right-most parameter the address of the temporary that will hold the result and the callee copies the value there. The start_call, call, and exit_proc methods are called with t=Struct. I want an additional mode. I want no extra parameter for struct return. My backend could easily pass and return them by value and hide the details. TYPE StructReturn = [None, Left, Right]; ? Too much is wrapped up in standard_structs -- pass and return could/should be separate. TYPE StructPass = [Value, Pointer]; ? I grant that really supporting this in the frontend might be a bit of work, and there might be little point, as the code is all rarely used. Maybe I should work on improving something else, e.g. scopes or global variables/segments. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 20 21:11:19 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 20 Apr 2013 21:11:19 +0200 Subject: [M3devel] "fork" In-Reply-To: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> Message-ID: <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> On Sat, 20 Apr 2013 12:52:58 +0200 Dragi?a Duri? wrote: > We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. > > My idea is basically to do this migration/fork without actually doing one. In short: > * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. > * Do all our work on SVN, > * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. > > This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. > > My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. > > We can also use GIT in one of two scenarios: > * Go straight from CVS to GIT, never look back; > * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. > > This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. > > I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. Indeed svn would be the easier way to go, but I'm not sure that is what most of the developers now want. In contrast to what I said two or three years ago, I now think that a migration away from CVS is overdue, but I haven't had the time to do it right and probably won't have that time in the near future. We _do_ have several svn and git experts in our company, but I haven't been able to inspire them to do the migration yet. Actually I think that the migration itself will be not very difficult; it is the Hudson/Jenkins/Apache/scripts support that will mostly need to be rewritten wrt. version control. I doubt that anybody outside of Elego has done much work on that. I'd like to try to acquire some internal ressources again; so I'd ask you to wait for some weeks. If I haven't been able to organize something until June, I'd think it will be best if someone else takes over completely. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sat Apr 20 21:51:10 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 20 Apr 2013 21:51:10 +0200 Subject: [M3devel] "fork" In-Reply-To: <20130420185340.GA5483@zoho.com> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420185340.GA5483@zoho.com> Message-ID: <64E848A5-4EAE-45D8-B116-A780741F25E9@m3w.org> Also monotone, Bazaar, mercurial? :) From fossil-users mailing list: > > Please guide me how do I convert CVS repository to fossil, > > preserving history and branches / tags. > > There is no generalized procedure for doing this. To convert SQLite > from CVS to fossil, I wrote a TCL script that checked out each > historical version of of SQL from CVS then checked it back into > fossil. It took several hours to run. I don't know where you got this information on "Linux only"? See http://git-scm.com/downloads If someone has better proposal, then please respond. -- Dragi?a Duri? dragisha at m3w.org On Apr 20, 2013, at 8:53 PM, microcode at zoho.com wrote: > Hi, what about fossi? (fossil-scm.org). It has a lot of nice features, > builds anywhere (unlike GIT which is hell to build anywhere but Linux) and > is from the author of SQLite- code is small and dead simple. > > > On Sat, Apr 20, 2013 at 12:52:58PM +0200, Dragi??a Duri?? wrote: >> We have this situation where Elego does not have neither interest nor resources to spare to do version control system migration. Projects like GCC and GNOME have abandoned CVS for good, and they are only two on a very long list. >> >> My idea is basically to do this migration/fork without actually doing one. In short: >> * We convert existing CVS to SVN, make CVS repository "read-only" i.e. single writer. >> * Do all our work on SVN, >> * Use svn2cvs to save SVN commits back to our "read-only" CVS repo. >> >> This way we get the best of both worlds. We have up-to-date CVS so all of our current infrastructure simply works. Process outlined is based on well-tested tools so we have little to no worries there. And we have as modern version control system as we can have without a distributed one. >> >> My first choice is SVN as a target because of easy way to maintain mirrored CVS repo, and thus reuse existing infrastructure. >> >> We can also use GIT in one of two scenarios: >> * Go straight from CVS to GIT, never look back; >> * add svn2git step to first "recipe" and use git2svn to sync back to svn repository from first step. >> >> This second variant looks like an overkill, but there are tools to maintain bidirectional mirroring of single git branch to a svn repo (esp. if this mirroring tools is only writer to svn repo). And all this is needed only in case we need (and I suppose we do) to maintain live CVS. >> >> I believe Elego will have no problems to extend their already great contribution to Modula-3 with few gigabytes of disk space and few configured processes. I would happily contribute my time and expertise to help with additional workload, and I am sure I am not only one willing to help. >> >> Thanks for reading this! :) >> dd >> >> -- >> Dragi??a Duri?? >> dragisha at m3w.org >> >> >> > > > > -- > _ _ > ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___ > | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._> > |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Apr 21 07:33:05 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Apr 2013 07:33:05 +0200 Subject: [M3devel] "fork" In-Reply-To: <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> Message-ID: <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> Well, this changes situation :). If nobody insists on CVS, then single jump from CVS to GIT is all we need. -- Dragi?a Duri? dragisha at m3w.org On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: > In contrast to what I said two or three years ago, I now think that > a migration away from CVS is overdue, but I haven't had the time to do it > right and probably won't have that time in the near future. We _do_ have > several svn and git experts in our company, but I haven't been able > to inspire them to do the migration yet. > > Actually I think that the migration itself will be not very difficult; it is > the Hudson/Jenkins/Apache/scripts support that will mostly need to be > rewritten wrt. version control. I doubt that anybody outside of Elego has > done much work on that. > > I'd like to try to acquire some internal ressources again; so I'd ask > you to wait for some weeks. If I haven't been able to organize something > until June, I'd think it will be best if someone else takes over completely. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Sun Apr 21 07:54:53 2013 From: peter.mckinna at gmail.com (Peter McKinna) Date: Sun, 21 Apr 2013 15:54:53 +1000 Subject: [M3devel] "fork" In-Reply-To: <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> Message-ID: Hi, I too support a clean move to git Great tool-set, very fast. The swig guys recently did a similar move to git, hosting it on github and all went very smoothly. Regards Peter On Sun, Apr 21, 2013 at 3:33 PM, Dragi?a Duri? wrote: > Well, this changes situation :). If nobody insists on CVS, then single > jump from CVS to GIT is all we need. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: > > In contrast to what I said two or three years ago, I now think that > a migration away from CVS is overdue, but I haven't had the time to do it > right and probably won't have that time in the near future. We _do_ have > several svn and git experts in our company, but I haven't been able > to inspire them to do the migration yet. > > Actually I think that the migration itself will be not very difficult; it > is > the Hudson/Jenkins/Apache/scripts support that will mostly need to be > rewritten wrt. version control. I doubt that anybody outside of Elego has > done much work on that. > > I'd like to try to acquire some internal ressources again; so I'd ask > you to wait for some weeks. If I haven't been able to organize something > until June, I'd think it will be best if someone else takes over > completely. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Apr 21 17:29:17 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Apr 2013 17:29:17 +0200 Subject: [M3devel] backend issues wrt garbage collection Message-ID: <4EB7E3F6-4D2A-4C0C-957A-49F813F60ABB@m3w.org> LLVM has a notion of a stacklet. So, stack is - possibly - non contiguous and as such it is not compatible with current GC. Fixable, but still an issue. Also, with C/C++ being a planned/developed backend, two issues emerge. One is - are global variables per module kept in contiguous space per module? Another is - what is compiler/backend/ABI/whatever of this final C/C++ compiler step and what it's stack is like? :) Also, are those global variable spaces kept contiguous regardless of optimizations? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dragisha at m3w.org Sun Apr 21 22:19:41 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Apr 2013 22:19:41 +0200 Subject: [M3devel] Trial conversion(s) Message-ID: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. Report tomorrow, or so :) -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Sun Apr 21 22:55:43 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Apr 2013 20:55:43 +0000 Subject: [M3devel] null type? Message-ID: What is the meaning of this: cm3/elego/graphicutils/src/RsrcFilter init(p1, p2, p3, p4, p5, p6 := NIL) : T; (* Initializes the resource search path. *) PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = What are the types of p1, p2, etc.? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 21 23:12:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Apr 2013 21:12:04 +0000 Subject: [M3devel] backend issues wrt garbage collection In-Reply-To: <4EB7E3F6-4D2A-4C0C-957A-49F813F60ABB@m3w.org> References: <4EB7E3F6-4D2A-4C0C-957A-49F813F60ABB@m3w.org> Message-ID: 1) Stack can/should be assumed contiguous. We don't handle IA64's two stacks properly though -- they grow up and down from same location. The one that grows up is for register spills. 2) It is very real. It has been working for months, building the entire system. Our Modula-3 implementation is perhaps "surprising". >From a certain point of view. There are two special structs per module, refered to as "segments", that contain the global read only data and global writable data. I would like to fix/change this at some point. There are significant disadvantages in the current scheme, and there are possible advantages, and reasons it is hard to change/fix. The disadvantages: none of the fields in the segments are named; it is highly non-debuggable. references to globals are via offsets -- the frontend has done the layout; fixing it, making them either named or separate variables, will require frontend work. For non-garbage collected data, I really don't see the point. For garbage collected data, there might be offsets recorded in yet more places. This either have to be preserved, or the offsets changed to pointers. There are advantages/disadvantages either way. Offsets can usually be smaller, e.g. only 32 bits on a 64bit target, and offsets imply an efficiency in the executable file and loading it -- i.e. fewer relocs or less indirection for position independent code. But ignoring those points and thinking from an idealized C point of view, separate data and pointers would be nice. Furthermore, separate variables give us a chance the compiler/linker can throw out unused data. However, the model here actually resembles what C compilers are forced to usually do anyway. Specifically, in a .c/.cpp file, you will generally get all the read only data linked in, or none of it, and all the writable data, or none of it. Linkers do NOT generally strip unused data. Given the code: int i; void *p = &foo; void foo() { } if "i" is referenced outside the file, then p and foo will be linked in as well, even if they are not otherwise used. In Microsoft Visual C++ you can do a bit better. You can mark constant ininitialized data as "__declspec(selectany)". The direct implied meaning is one thing, but the indirect meaning includes that it will be dead-stripped -- only linked in if referenced. I don't know how to do this with other compilers. The point is, these Modula-3 "segments" seem to closely emulate what most?all C compilers do anyway. But, they do it in a way that is guaranteed to be this way, even if some C compilers are different. However, I don't really see value in this approach. For C and C++ I think it is mostly subtle and unknown to programmers and causes the linker to bring in more code/data than is needed/expected. However, I expect it is also impossible to change without breaking some programs that depend on it. For Modula-3, I'm less worried about the changed semantics. Point being, if/when we separate out globals from "segments", I would be inclined to mark all the constants as __declspec(selectany), unless we know something further up the chain won't ever output unused data. We might also be able to win by using #pragma segment, a different segment for each data. > One is - are global variables per module kept in contiguous space per module? Yes. Two separate segments, for constants and non-constants. > Also, are those global variable spaces kept contiguous regardless of optimizations? Yes, probably, mostly. Depending on the underlying object model. Generally the underying system will have at least three sections/segments in the underyling object model -- read only executable code, read only non-executable data, writable non-executable data. Sometimes the read only data will be merged with the code. The readonly data and writable data will not necessarily be contiguous, and/or there could be a small gap between them. It really depends on the underlying system. But why does it matter? - Jay From: dragisha at m3w.org Date: Sun, 21 Apr 2013 17:29:17 +0200 To: m3devel at elegosoft.com Subject: [M3devel] backend issues wrt garbage collection LLVM has a notion of a stacklet. So, stack is - possibly - non contiguous and as such it is not compatible with current GC. Fixable, but still an issue. Also, with C/C++ being a planned/developed backend, two issues emerge. One is - are global variables per module kept in contiguous space per module? Another is - what is compiler/backend/ABI/whatever of this final C/C++ compiler step and what it's stack is like? :) Also, are those global variable spaces kept contiguous regardless of optimizations? --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Apr 21 23:49:03 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 21 Apr 2013 23:49:03 +0200 Subject: [M3devel] null type? In-Reply-To: References: Message-ID: <20130421234903.fbc4837a0cba1f1c28ebc2d7@elegosoft.com> On Sun, 21 Apr 2013 20:55:43 +0000 Jay K wrote: > What is the meaning of this: > > cm3/elego/graphicutils/src/RsrcFilter > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > (* Initializes the resource search path. *) > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > What are the types of p1, p2, etc.? Looks like REFANY; I think resources can actually be Bundle.Ts or TEXTs. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Mon Apr 22 00:45:05 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 22 Apr 2013 00:45:05 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> Message-ID: https://github.com/dragisha/cm3 Please check if it is ok, whoever has time/will. Please keep in mind this is preliminary. -- Dragi?a Duri? dragisha at m3w.org On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: > I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. > > Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. > > First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. > > Report tomorrow, or so :) > -- > Dragi?a Duri? > dragisha at m3w.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rodney_bates at lcwb.coop Mon Apr 22 04:03:02 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Apr 2013 21:03:02 -0500 Subject: [M3devel] null type? In-Reply-To: References: Message-ID: <51749A56.4070909@lcwb.coop> On 04/21/2013 03:55 PM, Jay K wrote: > What is the meaning of this: > > cm3/elego/graphicutils/src/RsrcFilter > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > (* Initializes the resource search path. *) > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > Modula-3 says: 2.2.7: 'The following reference types are predeclared: ... NULL Contains only NIL' And: 2.2.8: 'A formal parameter declaration has the form Mode Name: Type := Default ... If Type is omitted, it is taken to be the type of Default.' And: 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' So all the pi's have type NULL, and only NIL can be passed to them as actuals. That's what the language says. It looks like the code in Init thinks it can get non-NIL reference values, but an attempt to pass one in a call should fail a runtime assignability check, since it won't be a member of NULL. When Init passes one of these to Convert (Yes, I peeked into RsrcFilter.m3), it is assignable, with no runtime check. Convert thinks it has a REFANY, and other calls to Convert could indeed give it something non-NIL, but not from the calls in Init. Of course, unsafe code could probably LOOPHOLE (remember, any word can be verbed) something non-NIL to NULL and pass it to init/Init. If the compiler did the most obvious thing, this might do what was apparently intended. But then again, a compiler would be fully compliant with the language and perfectly within its rights to optimize out such a parameter, not actually pass it at runtime at all, and just insert constant NIL wherever the formal was referenced in the body of Init, thus undermining the above intent. Which makes for a good example of how unsafe code (almost?) always depends on assumptions about what a compiler will do. > > What are the types of p1, p2, etc.? > > > - Jay From hosking at cs.purdue.edu Mon Apr 22 05:20:52 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Apr 2013 15:20:52 +1200 Subject: [M3devel] "fork" In-Reply-To: References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> Message-ID: <9E39D415-6986-4C16-A701-D75D76AA40B9@cs.purdue.edu> What happens to all the commit logs? I'd hate to lose those. They carry useful information. Sent from my iPhone On 21/04/2013, at 5:54 PM, Peter McKinna wrote: > Hi, > > I too support a clean move to git Great tool-set, very fast. > > The swig guys recently did a similar move to git, hosting it on github and all went very smoothly. > > Regards > > Peter > > > On Sun, Apr 21, 2013 at 3:33 PM, Dragi?a Duri? wrote: >> Well, this changes situation :). If nobody insists on CVS, then single jump from CVS to GIT is all we need. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: >> >>> In contrast to what I said two or three years ago, I now think that >>> a migration away from CVS is overdue, but I haven't had the time to do it >>> right and probably won't have that time in the near future. We _do_ have >>> several svn and git experts in our company, but I haven't been able >>> to inspire them to do the migration yet. >>> >>> Actually I think that the migration itself will be not very difficult; it is >>> the Hudson/Jenkins/Apache/scripts support that will mostly need to be >>> rewritten wrt. version control. I doubt that anybody outside of Elego has >>> done much work on that. >>> >>> I'd like to try to acquire some internal ressources again; so I'd ask >>> you to wait for some weeks. If I haven't been able to organize something >>> until June, I'd think it will be best if someone else takes over completely. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Apr 22 07:49:27 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 22 Apr 2013 07:49:27 +0200 Subject: [M3devel] "fork" In-Reply-To: <9E39D415-6986-4C16-A701-D75D76AA40B9@cs.purdue.edu> References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org> <20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com> <1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org> <9E39D415-6986-4C16-A701-D75D76AA40B9@cs.purdue.edu> Message-ID: <0F4CAC04-4699-4134-A246-4A6E07C2966A@m3w.org> Absolutely preserved. That's a reason why our choices are svn and git - there are great migration tools. -- Dragi?a Duri? dragisha at m3w.org On Apr 22, 2013, at 5:20 AM, Tony Hosking wrote: > What happens to all the commit logs? I'd hate to lose those. They carry useful information. > > Sent from my iPhone > > On 21/04/2013, at 5:54 PM, Peter McKinna wrote: > >> Hi, >> >> I too support a clean move to git Great tool-set, very fast. >> >> The swig guys recently did a similar move to git, hosting it on github and all went very smoothly. >> >> Regards >> >> Peter >> >> >> On Sun, Apr 21, 2013 at 3:33 PM, Dragi?a Duri? wrote: >> Well, this changes situation :). If nobody insists on CVS, then single jump from CVS to GIT is all we need. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 20, 2013, at 9:11 PM, Olaf Wagner wrote: >> >>> In contrast to what I said two or three years ago, I now think that >>> a migration away from CVS is overdue, but I haven't had the time to do it >>> right and probably won't have that time in the near future. We _do_ have >>> several svn and git experts in our company, but I haven't been able >>> to inspire them to do the migration yet. >>> >>> Actually I think that the migration itself will be not very difficult; it is >>> the Hudson/Jenkins/Apache/scripts support that will mostly need to be >>> rewritten wrt. version control. I doubt that anybody outside of Elego has >>> done much work on that. >>> >>> I'd like to try to acquire some internal ressources again; so I'd ask >>> you to wait for some weeks. If I haven't been able to organize something >>> until June, I'd think it will be best if someone else takes over completely. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Apr 22 08:46:22 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 22 Apr 2013 08:46:22 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> Message-ID: <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> http://pastebin.com/pWvsYqdj Tags converted, in final phase. All comments, changesets? Came before, during conversion process on my computer. -- Dragi?a Duri? dragisha at m3w.org On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: > https://github.com/dragisha/cm3 > > Please check if it is ok, whoever has time/will. > > Please keep in mind this is preliminary. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: > >> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >> >> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >> >> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >> >> Report tomorrow, or so :) >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Mon Apr 22 19:38:28 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Apr 2013 17:38:28 +0000 Subject: [M3devel] null type? In-Reply-To: <51749A56.4070909@lcwb.coop> References: , <51749A56.4070909@lcwb.coop> Message-ID: Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it.This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. - Jay > Date: Sun, 21 Apr 2013 21:03:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] null type? > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > What is the meaning of this: > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > (* Initializes the resource search path. *) > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > Modula-3 says: > > 2.2.7: 'The following reference types are predeclared: > ... > NULL Contains only NIL' > > And: > > 2.2.8: 'A formal parameter declaration has the form > Mode Name: Type := Default > ... > If Type is omitted, it is taken to be the type of Default.' > > And: > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > So all the pi's have type NULL, and only NIL can be passed to them > as actuals. That's what the language says. It looks like the code > in Init thinks it can get non-NIL reference values, but an attempt to pass > one in a call should fail a runtime assignability check, since it > won't be a member of NULL. > > When Init passes one of these to Convert (Yes, I peeked into > RsrcFilter.m3), it is assignable, with no runtime check. Convert > thinks it has a REFANY, and other calls to Convert could indeed > give it something non-NIL, but not from the calls in Init. > > Of course, unsafe code could probably LOOPHOLE (remember, any word > can be verbed) something non-NIL to NULL and pass it to init/Init. > If the compiler did the most obvious thing, this might do what was > apparently intended. > > But then again, a compiler would be fully compliant with the language > and perfectly within its rights to optimize out such a parameter, > not actually pass it at runtime at all, and just insert constant NIL > wherever the formal was referenced in the body of Init, thus undermining > the above intent. > > Which makes for a good example of how unsafe code (almost?) always > depends on assumptions about what a compiler will do. > > > > > What are the types of p1, p2, etc.? > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Apr 22 19:59:30 2013 From: darko at darko.org (Darko) Date: Mon, 22 Apr 2013 10:59:30 -0700 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop> Message-ID: A type denotes a set of allowable values. The NULL type is the set of values that only contains the value NIL. You need it because every expression has a static type so you need one for the expression "NIL". This to me looks like a bug. I have something similar in my code, declared CONST Nil: REFANY = Nil; so I can write PROCEDURE(a, b, c := Nil). Maybe that's what they had in mind but thinking the type of NIL was REFANY. On Apr 22, 2013, at 10:38 AM, Jay K wrote: > Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. > This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. > > > - Jay > > > Date: Sun, 21 Apr 2013 21:03:02 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] null type? > > > > > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > > What is the meaning of this: > > > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > > (* Initializes the resource search path. *) > > > > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > > > > Modula-3 says: > > > > 2.2.7: 'The following reference types are predeclared: > > ... > > NULL Contains only NIL' > > > > And: > > > > 2.2.8: 'A formal parameter declaration has the form > > Mode Name: Type := Default > > ... > > If Type is omitted, it is taken to be the type of Default.' > > > > And: > > > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > > > So all the pi's have type NULL, and only NIL can be passed to them > > as actuals. That's what the language says. It looks like the code > > in Init thinks it can get non-NIL reference values, but an attempt to pass > > one in a call should fail a runtime assignability check, since it > > won't be a member of NULL. > > > > When Init passes one of these to Convert (Yes, I peeked into > > RsrcFilter.m3), it is assignable, with no runtime check. Convert > > thinks it has a REFANY, and other calls to Convert could indeed > > give it something non-NIL, but not from the calls in Init. > > > > Of course, unsafe code could probably LOOPHOLE (remember, any word > > can be verbed) something non-NIL to NULL and pass it to init/Init. > > If the compiler did the most obvious thing, this might do what was > > apparently intended. > > > > But then again, a compiler would be fully compliant with the language > > and perfectly within its rights to optimize out such a parameter, > > not actually pass it at runtime at all, and just insert constant NIL > > wherever the formal was referenced in the body of Init, thus undermining > > the above intent. > > > > Which makes for a good example of how unsafe code (almost?) always > > depends on assumptions about what a compiler will do. > > > > > > > > What are the types of p1, p2, etc.? > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Apr 22 20:13:16 2013 From: darko at darko.org (Darko) Date: Mon, 22 Apr 2013 11:13:16 -0700 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop> Message-ID: That should read CONST Nil: REFANY = NIL; and no, you can't treat it like ADDRESS, it's equivalent to the enumeration TYPE NULL = {NIL}; On Apr 22, 2013, at 10:59 AM, Darko wrote: > A type denotes a set of allowable values. The NULL type is the set of values that only contains the value NIL. You need it because every expression has a static type so you need one for the expression "NIL". > > This to me looks like a bug. I have something similar in my code, declared CONST Nil: REFANY = Nil; so I can write PROCEDURE(a, b, c := Nil). Maybe that's what they had in mind but thinking the type of NIL was REFANY. > > > On Apr 22, 2013, at 10:38 AM, Jay K wrote: > >> Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. >> This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. >> >> >> - Jay >> >> > Date: Sun, 21 Apr 2013 21:03:02 -0500 >> > From: rodney_bates at lcwb.coop >> > To: m3devel at elegosoft.com >> > Subject: Re: [M3devel] null type? >> > >> > >> > >> > On 04/21/2013 03:55 PM, Jay K wrote: >> > > What is the meaning of this: >> > > >> > > cm3/elego/graphicutils/src/RsrcFilter >> > > >> > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; >> > > (* Initializes the resource search path. *) >> > > >> > > >> > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = >> > > >> > >> > Modula-3 says: >> > >> > 2.2.7: 'The following reference types are predeclared: >> > ... >> > NULL Contains only NIL' >> > >> > And: >> > >> > 2.2.8: 'A formal parameter declaration has the form >> > Mode Name: Type := Default >> > ... >> > If Type is omitted, it is taken to be the type of Default.' >> > >> > And: >> > >> > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' >> > >> > So all the pi's have type NULL, and only NIL can be passed to them >> > as actuals. That's what the language says. It looks like the code >> > in Init thinks it can get non-NIL reference values, but an attempt to pass >> > one in a call should fail a runtime assignability check, since it >> > won't be a member of NULL. >> > >> > When Init passes one of these to Convert (Yes, I peeked into >> > RsrcFilter.m3), it is assignable, with no runtime check. Convert >> > thinks it has a REFANY, and other calls to Convert could indeed >> > give it something non-NIL, but not from the calls in Init. >> > >> > Of course, unsafe code could probably LOOPHOLE (remember, any word >> > can be verbed) something non-NIL to NULL and pass it to init/Init. >> > If the compiler did the most obvious thing, this might do what was >> > apparently intended. >> > >> > But then again, a compiler would be fully compliant with the language >> > and perfectly within its rights to optimize out such a parameter, >> > not actually pass it at runtime at all, and just insert constant NIL >> > wherever the formal was referenced in the body of Init, thus undermining >> > the above intent. >> > >> > Which makes for a good example of how unsafe code (almost?) always >> > depends on assumptions about what a compiler will do. >> > >> > > >> > > What are the types of p1, p2, etc.? >> > > >> > > >> > > - Jay >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Tue Apr 23 01:29:06 2013 From: lists at darko.org (Darko Volaric) Date: Mon, 22 Apr 2013 16:29:06 -0700 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> Message-ID: There's another aspect of the NULL type which should be considered here. NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor of all reference types, NULL is the ultimate descendant of all reference types. As a result any variable of a reference type can be assigned NIL. Because of its unusual position, NIL is the only member of type NULL, since no other value makes sense (which is why it's sometimes called the "absurd" type). On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: > Disclosure: I knew they are of type "NULL", but I didn't/don't know what > that type is, or have a mental model for it. > This about the only place in the entire tree that uses this type. It > triggers an error in the C backend, but should be trivial to fix. I can > just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the > frontend's job. The error is just that I check that I know about every > type. Some types are "predeclared", some come from the frontend. I'll > predeclare this. Arguably nothing should be predeclared. > > > - Jay > > > Date: Sun, 21 Apr 2013 21:03:02 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] null type? > > > > > > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > > What is the meaning of this: > > > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > > (* Initializes the resource search path. *) > > > > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > > > > Modula-3 says: > > > > 2.2.7: 'The following reference types are predeclared: > > ... > > NULL Contains only NIL' > > > > And: > > > > 2.2.8: 'A formal parameter declaration has the form > > Mode Name: Type := Default > > ... > > If Type is omitted, it is taken to be the type of Default.' > > > > And: > > > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > > > So all the pi's have type NULL, and only NIL can be passed to them > > as actuals. That's what the language says. It looks like the code > > in Init thinks it can get non-NIL reference values, but an attempt to > pass > > one in a call should fail a runtime assignability check, since it > > won't be a member of NULL. > > > > When Init passes one of these to Convert (Yes, I peeked into > > RsrcFilter.m3), it is assignable, with no runtime check. Convert > > thinks it has a REFANY, and other calls to Convert could indeed > > give it something non-NIL, but not from the calls in Init. > > > > Of course, unsafe code could probably LOOPHOLE (remember, any word > > can be verbed) something non-NIL to NULL and pass it to init/Init. > > If the compiler did the most obvious thing, this might do what was > > apparently intended. > > > > But then again, a compiler would be fully compliant with the language > > and perfectly within its rights to optimize out such a parameter, > > not actually pass it at runtime at all, and just insert constant NIL > > wherever the formal was referenced in the body of Init, thus undermining > > the above intent. > > > > Which makes for a good example of how unsafe code (almost?) always > > depends on assumptions about what a compiler will do. > > > > > > > > What are the types of p1, p2, etc.? > > > > > > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 23 06:49:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Apr 2013 04:49:25 +0000 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop>, , Message-ID: > That should read CONST Nil: REFANY = NIL; and no, you can't > treat it like ADDRESS, it's equivalent to the enumeration TYPE NULL = {NIL}; At the backend level? It is always CGType.Addr, right? And there are not fields within a struct being pointed to, right? Our backend interface has two type systems. 1) CGType = roughly [int8, uint8, int16, uint16, int32, uint32, int64, uint64, float, double, extended, addr, struct] That is it -- pointers are just addresses, no type beyond that. Be they record pointers or objects or VAR parameters. Structs have a size associated with them as needed. But no fields. 2) typeids, opaques, structs, enums, typenames, objects, fields, methods They are overlapping. The NTx86 backend does nothing with the second set of types, and it works, and it is correct. Debugging is not good. The gcc backend, only for some targets, encodes the second set of types in strange ways that only m3gdb understands. They have no affect on codegen, and some targets, e.g. Darwin and I think HP-UX, ignore them entirely. Debugging is not good on Darwin or with stock debuggers. In the C backend, originally, I also ignored the second set. And again, it works but debugging was poor.Now in the C backend, I pay a lot of attention to the second set and it is much better. Not quite done, but getting there. The question is in that context. Given a variable/parameter of type NULL, what is its best most typeful representation in C or C++?Probably just void* or char*. - Jay Date: Mon, 22 Apr 2013 16:29:06 -0700 From: lists at darko.org To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] null type? There's another aspect of the NULL type which should be considered here. NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor of all reference types, NULL is the ultimate descendant of all reference types. As a result any variable of a reference type can be assigned NIL. Because of its unusual position, NIL is the only member of type NULL, since no other value makes sense (which is why it's sometimes called the "absurd" type). On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. - Jay > Date: Sun, 21 Apr 2013 21:03:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] null type? > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > What is the meaning of this: > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > (* Initializes the resource search path. *) > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > Modula-3 says: > > 2.2.7: 'The following reference types are predeclared: > ... > NULL Contains only NIL' > > And: > > 2.2.8: 'A formal parameter declaration has the form > Mode Name: Type := Default > ... > If Type is omitted, it is taken to be the type of Default.' > > And: > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > So all the pi's have type NULL, and only NIL can be passed to them > as actuals. That's what the language says. It looks like the code > in Init thinks it can get non-NIL reference values, but an attempt to pass > one in a call should fail a runtime assignability check, since it > won't be a member of NULL. > > When Init passes one of these to Convert (Yes, I peeked into > RsrcFilter.m3), it is assignable, with no runtime check. Convert > thinks it has a REFANY, and other calls to Convert could indeed > give it something non-NIL, but not from the calls in Init. > > Of course, unsafe code could probably LOOPHOLE (remember, any word > can be verbed) something non-NIL to NULL and pass it to init/Init. > If the compiler did the most obvious thing, this might do what was > apparently intended. > > But then again, a compiler would be fully compliant with the language > and perfectly within its rights to optimize out such a parameter, > not actually pass it at runtime at all, and just insert constant NIL > wherever the formal was referenced in the body of Init, thus undermining > the above intent. > > Which makes for a good example of how unsafe code (almost?) always > depends on assumptions about what a compiler will do. > > > > > What are the types of p1, p2, etc.? > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 23 07:24:11 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 23 Apr 2013 07:24:11 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> Message-ID: Anybody had a look at final conversion? Jay? -- Dragi?a Duri? dragisha at m3w.org On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: > http://pastebin.com/pWvsYqdj > > Tags converted, in final phase. All comments, changesets? Came before, during conversion process on my computer. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: > >> https://github.com/dragisha/cm3 >> >> Please check if it is ok, whoever has time/will. >> >> Please keep in mind this is preliminary. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >> >>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>> >>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>> >>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>> >>> Report tomorrow, or so :) >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Tue Apr 23 23:37:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Apr 2013 21:37:33 +0000 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, Message-ID: I have pretty much never used git or svn. I learn new source control systems kinda slowly.I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. Thank you, - Jay From: dragisha at m3w.org Date: Tue, 23 Apr 2013 07:24:11 +0200 To: m3devel at elegosoft.com Subject: Re: [M3devel] Trial conversion(s) Anybody had a look at final conversion? Jay? --Dragi?a Duri?dragisha at m3w.org On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote:http://pastebin.com/pWvsYqdj Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. --Dragi?a Duri?dragisha at m3w.org On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote:https://github.com/dragisha/cm3 Please check if it is ok, whoever has time/will. Please keep in mind this is preliminary. --Dragi?a Duri?dragisha at m3w.org On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote:I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. Report tomorrow, or so :) --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 24 02:14:36 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 23 Apr 2013 17:14:36 -0700 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> Message-ID: <20130424001436.F01F01A207D@async.async.caltech.edu> I'm pretty sure the original code is buggy. The best type to represent NULL in C(++) I think would be no type at all, that is, strip the parameter and replace it with a constant (void *)0. Of course you might have some mismatches if you do that. Second closest would be some singleton type. But I would add that there has been a Modula-3 compiler that treats a declaration of a := NIL as a : REFANY := NIL but that was a buggy compiler. I had made the mistake in my own code a few times and when I upgraded my compiler once, it stopped working (as it should have). Mika Darko Volaric writes: >--047d7bd76f785e671604dafb6f57 >Content-Type: text/plain; charset=ISO-8859-1 > >There's another aspect of the NULL type which should be considered here. >NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor >of all reference types, NULL is the ultimate descendant of >all reference types. As a result any variable of a reference type can be >assigned NIL. Because of its unusual position, NIL is the only member of >type NULL, since no other value makes sense (which is why it's sometimes >called the "absurd" type). > > >On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: > >> Disclosure: I knew they are of type "NULL", but I didn't/don't know what >> that type is, or have a mental model for it. >> This about the only place in the entire tree that uses this type. It >> triggers an error in the C backend, but should be trivial to fix. I can >> just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the >> frontend's job. The error is just that I check that I know about every >> type. Some types are "predeclared", some come from the frontend. I'll >> predeclare this. Arguably nothing should be predeclared. >> >> >> - Jay >> >> > Date: Sun, 21 Apr 2013 21:03:02 -0500 >> > From: rodney_bates at lcwb.coop >> > To: m3devel at elegosoft.com >> > Subject: Re: [M3devel] null type? >> >> > >> > >> > >> > On 04/21/2013 03:55 PM, Jay K wrote: >> > > What is the meaning of this: >> > > >> > > cm3/elego/graphicutils/src/RsrcFilter >> > > >> > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; >> > > (* Initializes the resource search path. *) >> > > >> > > >> > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = >> > > >> > >> > Modula-3 says: >> > >> > 2.2.7: 'The following reference types are predeclared: >> > ... >> > NULL Contains only NIL' >> > >> > And: >> > >> > 2.2.8: 'A formal parameter declaration has the form >> > Mode Name: Type := Default >> > ... >> > If Type is omitted, it is taken to be the type of Default.' >> > >> > And: >> > >> > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' >> > >> > So all the pi's have type NULL, and only NIL can be passed to them >> > as actuals. That's what the language says. It looks like the code >> > in Init thinks it can get non-NIL reference values, but an attempt to >> pass >> > one in a call should fail a runtime assignability check, since it >> > won't be a member of NULL. >> > >> > When Init passes one of these to Convert (Yes, I peeked into >> > RsrcFilter.m3), it is assignable, with no runtime check. Convert >> > thinks it has a REFANY, and other calls to Convert could indeed >> > give it something non-NIL, but not from the calls in Init. >> > >> > Of course, unsafe code could probably LOOPHOLE (remember, any word >> > can be verbed) something non-NIL to NULL and pass it to init/Init. >> > If the compiler did the most obvious thing, this might do what was >> > apparently intended. >> > >> > But then again, a compiler would be fully compliant with the language >> > and perfectly within its rights to optimize out such a parameter, >> > not actually pass it at runtime at all, and just insert constant NIL >> > wherever the formal was referenced in the body of Init, thus undermining >> > the above intent. >> > >> > Which makes for a good example of how unsafe code (almost?) always >> > depends on assumptions about what a compiler will do. >> > >> > > >> > > What are the types of p1, p2, etc.? >> > > >> > > >> > > - Jay >> > >> > >--047d7bd76f785e671604dafb6f57 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > >
There's another aspect of the NULL type which should b= >e considered here. NULL is the complement of REFANY. Just as REFANY is the = >ultimate ancestor of all reference types, NULL is the ultimate=A0descendant= > of all=A0reference=A0types. As a result any variable of a reference type c= >an be assigned NIL.=A0Because=A0of its unusual position, NIL is the only me= >mber of type NULL, since no other value makes sense (which is why it's = >sometimes called the "absurd" type).
>


On Mon, Apr 2= >2, 2013 at 10:38 AM, Jay K <l at cornell.edu" target=3D"_blank">jay.krell at cornell.edu> wrote= >:
ft:1px #ccc solid;padding-left:1ex"> > > > >
Disclosure: I knew they are of type "NULL",= > but I didn't/don't know what that type is, or have a mental model = >for it.
This about the only place in the entire tree that uses this type= >. It triggers an error in the C backend, but should be trivial to fix. I ca= >n just treat this as=A0"ADDRESS" presumably. Checks that it is NI= >L, that is the frontend's job. The error is just that I check that I kn= >ow about every type. Some types are "predeclared", some come from= > the frontend. I'll predeclare this. Arguably nothing should be predecl= >ared.
>=A0
=A0
=A0=A0- Jay
=A0
> Date: Sun, 21 Apr = >2013 21:03:02 -0500
> From: target=3D"_blank">rodney_bates at lcwb.coop
> To: :m3devel at elegosoft.com" target=3D"_blank">m3devel at elegosoft.com
>> Subject: Re: [M3devel] null type?

>
&= >gt;
>
> On 04/21/2013 03:55 PM, Jay K wrote:
> > Wha= >t is the meaning of this:
> >
> > cm3/elego/graphicutils/= >src/RsrcFilter
>> >
> > init(p1, p2, p3, p4, p5, p6 :=3D NIL) : T;
&= >gt; > (* Initializes the resource search path. *)
> >
&= >gt; >
> > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 :=3D = >NIL) : T =3D
>> >
>
> Modula-3 says:
>
> 2.2.7: 'The = >following reference types are predeclared:
> ...
> = > NULL Contains only NIL'
>
> And:
>
> = >2.2.8: 'A formal parameter declaration has the form
>> Mode Name: Type :=3D Default
> ...
> = > If Type is omitted, it is taken to be the type of Default.'
= >>
> And:
>
> 2.6.6: 'The literal "NIL"= > denotes the value NIL. Its type is NULL.'
>>
> So all the pi's have type NULL, and only NIL can be passe= >d to them
> as actuals. That's what the language says. It look= >s like the code
> in Init thinks it can get non-NIL reference values,= > but an attempt to pass
>> one in a call should fail a runtime assignability check, since it
&= >gt; won't be a member of NULL.
>
> When Init passes one of= > these to Convert (Yes, I peeked into
> RsrcFilter.m3), it is assigna= >ble, with no runtime check. Convert
>> thinks it has a REFANY, and other calls to Convert could indeed
>= >; give it something non-NIL, but not from the calls in Init.
>
&g= >t; Of course, unsafe code could probably LOOPHOLE (remember, any word
>> can be verbed) something non-NIL to NULL and pass it to init/Init.
= >> If the compiler did the most obvious thing, this might do what was
= >> apparently intended.
>
> But then again, a compiler would= > be fully compliant with the language
>> and perfectly within its rights to optimize out such a parameter,
&= >gt; not actually pass it at runtime at all, and just insert constant NIL>> wherever the formal was referenced in the body of Init, thus undermin= >ing
>> the above intent.
>
> Which makes for a good example of h= >ow unsafe code (almost?) always
> depends on assumptions about what a= > compiler will do.
>
> >
> > What are the types of= > p1, p2, etc.?
>> >
> >
> > - Jay
>
= >
>

> >--047d7bd76f785e671604dafb6f57-- From hendrik at topoi.pooq.com Wed Apr 24 05:09:39 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 23 Apr 2013 23:09:39 -0400 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> Message-ID: <20130424030938.GA32407@topoi.pooq.com> On Mon, Apr 22, 2013 at 04:29:06PM -0700, Darko Volaric wrote: > There's another aspect of the NULL type which should be considered here. > NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor > of all reference types, NULL is the ultimate descendant of > all reference types. As a result any variable of a reference type can be > assigned NIL. Because of its unusual position, NIL is the only member of > type NULL, since no other value makes sense (which is why it's sometimes > called the "absurd" type). I think that terminology comes from the type lattice, and perhaps also from the propositions as types formalism. The type that is properly "absurd" is the type with no elements at all, corresponding to the empty set. A functino returning a value of this type can never return, because there are no values of that type. But since Modula 3 (as many other languages) has no truly empty type, the bottom of the type lattice is NULL, and I suppose its kind of plausible that it get called "absurd" for that reason. -- hendrik From dragisha at m3w.org Wed Apr 24 07:55:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 24 Apr 2013 07:55:15 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, Message-ID: <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ I've used githowto.com some time ago. Looks great. It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. dd -- Dragi?a Duri? dragisha at m3w.org On Apr 23, 2013, at 11:37 PM, Jay K wrote: > I have pretty much never used git or svn. I learn new source control systems kinda slowly. > I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. > > Thank you, > - Jay > > From: dragisha at m3w.org > Date: Tue, 23 Apr 2013 07:24:11 +0200 > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Trial conversion(s) > > Anybody had a look at final conversion? Jay? > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: > > http://pastebin.com/pWvsYqdj > > Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: > > https://github.com/dragisha/cm3 > > Please check if it is ok, whoever has time/will. > > Please keep in mind this is preliminary. > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: > > I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. > > Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. > > First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. > > Report tomorrow, or so :) > -- > Dragi?a Duri? > dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 24 08:50:33 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 24 Apr 2013 08:50:33 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> Message-ID: I only checked Windows tools now, and found this: http://windows.github.com/ There is also github for Mac. On Unix/Linux it is native. For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). dd On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: > I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ > > I've used githowto.com some time ago. Looks great. > > It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. > > dd > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 23, 2013, at 11:37 PM, Jay K wrote: > >> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >> >> Thank you, >> - Jay >> >> From: dragisha at m3w.org >> Date: Tue, 23 Apr 2013 07:24:11 +0200 >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Trial conversion(s) >> >> Anybody had a look at final conversion? Jay? >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >> >> http://pastebin.com/pWvsYqdj >> >> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >> >> https://github.com/dragisha/cm3 >> >> Please check if it is ok, whoever has time/will. >> >> Please keep in mind this is preliminary. >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >> >> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >> >> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >> >> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >> >> Report tomorrow, or so :) >> -- >> Dragi?a Duri? >> dragisha at m3w.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 24 14:16:29 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 24 Apr 2013 14:16:29 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> Message-ID: <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> I don't know, really. Have you tried? -- Dragi?a Duri? dragisha at m3w.org On Apr 24, 2013, at 1:52 PM, Darko wrote: > Is there no way for us to sign up as collaborators ourselves and be approved? > > > On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: > >> I only checked Windows tools now, and found this: http://windows.github.com/ >> >> There is also github for Mac. >> >> On Unix/Linux it is native. >> >> For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). >> >> dd >> >> On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: >> >>> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >>> >>> I've used githowto.com some time ago. Looks great. >>> >>> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >>> >>> dd >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >>> >>>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>>> >>>> Thank you, >>>> - Jay >>>> >>>> From: dragisha at m3w.org >>>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>>> To: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Trial conversion(s) >>>> >>>> Anybody had a look at final conversion? Jay? >>>> >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>>> >>>> http://pastebin.com/pWvsYqdj >>>> >>>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>>> >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>>> >>>> https://github.com/dragisha/cm3 >>>> >>>> Please check if it is ok, whoever has time/will. >>>> >>>> Please keep in mind this is preliminary. >>>> >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>>> >>>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>>> >>>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>>> >>>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>>> >>>> Report tomorrow, or so :) >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 13:52:55 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 04:52:55 -0700 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> Message-ID: Is there no way for us to sign up as collaborators ourselves and be approved? On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: > I only checked Windows tools now, and found this: http://windows.github.com/ > > There is also github for Mac. > > On Unix/Linux it is native. > > For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). > > dd > > On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: > >> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >> >> I've used githowto.com some time ago. Looks great. >> >> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >> >> dd >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >> >>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>> >>> Thank you, >>> - Jay >>> >>> From: dragisha at m3w.org >>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Trial conversion(s) >>> >>> Anybody had a look at final conversion? Jay? >>> >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>> >>> http://pastebin.com/pWvsYqdj >>> >>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>> >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>> >>> https://github.com/dragisha/cm3 >>> >>> Please check if it is ok, whoever has time/will. >>> >>> Please keep in mind this is preliminary. >>> >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >>> >>> >>> >>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>> >>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>> >>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>> >>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>> >>> Report tomorrow, or so :) >>> -- >>> Dragi?a Duri? >>> dragisha at m3w.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 15:40:23 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 06:40:23 -0700 Subject: [M3devel] Trial conversion(s) In-Reply-To: <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> Message-ID: There doesn't seem to be an option to add yourself as a collaborator to that repository. Can we open a "cm3" organization account for the final repository? On Apr 24, 2013, at 5:16 AM, Dragi?a Duri? wrote: > I don't know, really. Have you tried? > > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 24, 2013, at 1:52 PM, Darko wrote: > >> Is there no way for us to sign up as collaborators ourselves and be approved? >> >> >> On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: >> >>> I only checked Windows tools now, and found this: http://windows.github.com/ >>> >>> There is also github for Mac. >>> >>> On Unix/Linux it is native. >>> >>> For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). >>> >>> dd >>> >>> On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: >>> >>>> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >>>> >>>> I've used githowto.com some time ago. Looks great. >>>> >>>> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >>>> >>>> dd >>>> -- >>>> Dragi?a Duri? >>>> dragisha at m3w.org >>>> >>>> >>>> >>>> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >>>> >>>>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>>>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>>>> >>>>> Thank you, >>>>> - Jay >>>>> >>>>> From: dragisha at m3w.org >>>>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] Trial conversion(s) >>>>> >>>>> Anybody had a look at final conversion? Jay? >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>>>> >>>>> http://pastebin.com/pWvsYqdj >>>>> >>>>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>>>> >>>>> https://github.com/dragisha/cm3 >>>>> >>>>> Please check if it is ok, whoever has time/will. >>>>> >>>>> Please keep in mind this is preliminary. >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>>>> >>>>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>>>> >>>>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>>>> >>>>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>>>> >>>>> Report tomorrow, or so :) >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 14:10:45 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 05:10:45 -0700 Subject: [M3devel] null type? In-Reply-To: References: , <51749A56.4070909@lcwb.coop>, , Message-ID: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> I think the correct approach is to treat a variable declaration with a type NULL as an error. The correspondence to C would be void, but just void, not void*. What is the representation of the declaration "void x"? I'm guessing C doesn't allow that. On Apr 22, 2013, at 9:49 PM, Jay K wrote: > > That should read CONST Nil: REFANY = NIL; and no, you can't > > treat it like ADDRESS, it's equivalent to the enumeration TYPE NULL = {NIL}; > > At the backend level? > It is always CGType.Addr, right? > And there are not fields within a struct being pointed to, right? > > > Our backend interface has two type systems. > 1) CGType = roughly [int8, uint8, int16, uint16, int32, uint32, int64, uint64, float, double, extended, addr, struct] > That is it -- pointers are just addresses, no type beyond that. Be they record pointers or objects or VAR parameters. > Structs have a size associated with them as needed. But no fields. > 2) typeids, opaques, structs, enums, typenames, objects, fields, methods > > > They are overlapping. > The NTx86 backend does nothing with the second set of types, and it works, and it is correct. Debugging is not good. > The gcc backend, only for some targets, encodes the second set of types in strange ways that only m3gdb understands. They have no affect on codegen, and some targets, e.g. Darwin and I think HP-UX, ignore them entirely. Debugging is not good on Darwin or with stock debuggers. > > > In the C backend, originally, I also ignored the second set. And again, it works but debugging was poor. > Now in the C backend, I pay a lot of attention to the second set and it is much better. Not quite done, but getting there. > > > The question is in that context. > > > Given a variable/parameter of type NULL, what is its best most typeful representation in C or C++? > Probably just void* or char*. > > > - Jay > Date: Mon, 22 Apr 2013 16:29:06 -0700 > From: lists at darko.org > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] null type? > > There's another aspect of the NULL type which should be considered here. NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor of all reference types, NULL is the ultimate descendant of all reference types. As a result any variable of a reference type can be assigned NIL. Because of its unusual position, NIL is the only member of type NULL, since no other value makes sense (which is why it's sometimes called the "absurd" type). > > > On Mon, Apr 22, 2013 at 10:38 AM, Jay K wrote: > Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it. > This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared. > > > - Jay > > > Date: Sun, 21 Apr 2013 21:03:02 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] null type? > > > > > > > > > On 04/21/2013 03:55 PM, Jay K wrote: > > > What is the meaning of this: > > > > > > cm3/elego/graphicutils/src/RsrcFilter > > > > > > init(p1, p2, p3, p4, p5, p6 := NIL) : T; > > > (* Initializes the resource search path. *) > > > > > > > > > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T = > > > > > > > Modula-3 says: > > > > 2.2.7: 'The following reference types are predeclared: > > ... > > NULL Contains only NIL' > > > > And: > > > > 2.2.8: 'A formal parameter declaration has the form > > Mode Name: Type := Default > > ... > > If Type is omitted, it is taken to be the type of Default.' > > > > And: > > > > 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.' > > > > So all the pi's have type NULL, and only NIL can be passed to them > > as actuals. That's what the language says. It looks like the code > > in Init thinks it can get non-NIL reference values, but an attempt to pass > > one in a call should fail a runtime assignability check, since it > > won't be a member of NULL. > > > > When Init passes one of these to Convert (Yes, I peeked into > > RsrcFilter.m3), it is assignable, with no runtime check. Convert > > thinks it has a REFANY, and other calls to Convert could indeed > > give it something non-NIL, but not from the calls in Init. > > > > Of course, unsafe code could probably LOOPHOLE (remember, any word > > can be verbed) something non-NIL to NULL and pass it to init/Init. > > If the compiler did the most obvious thing, this might do what was > > apparently intended. > > > > But then again, a compiler would be fully compliant with the language > > and perfectly within its rights to optimize out such a parameter, > > not actually pass it at runtime at all, and just insert constant NIL > > wherever the formal was referenced in the body of Init, thus undermining > > the above intent. > > > > Which makes for a good example of how unsafe code (almost?) always > > depends on assumptions about what a compiler will do. > > > > > > > > What are the types of p1, p2, etc.? > > > > > > > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 24 14:02:18 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 05:02:18 -0700 Subject: [M3devel] null type? In-Reply-To: <20130424030938.GA32407@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <20130424030938.GA32407@topoi.pooq.com> Message-ID: It does come from the idea of the type lattice, but I think it's an important abstraction when thinking about types in any language. In my mind the "absurdity" is the idea that there can be some type that is a subtype of all things. Of course there is nothing that can be that, but even nothing has to be represented as some thing. In other languages a value of this bottom type is called "failure", which I think makes it clearer. "Null" is often interpreted as "don't know or don't care", which leadings to people thinking about the bottom type instead as the top type, so we have people assuming the type of NIL is REFANY. On Apr 23, 2013, at 8:09 PM, Hendrik Boom wrote: > On Mon, Apr 22, 2013 at 04:29:06PM -0700, Darko Volaric wrote: >> There's another aspect of the NULL type which should be considered here. >> NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor >> of all reference types, NULL is the ultimate descendant of >> all reference types. As a result any variable of a reference type can be >> assigned NIL. Because of its unusual position, NIL is the only member of >> type NULL, since no other value makes sense (which is why it's sometimes >> called the "absurd" type). > > I think that terminology comes from the type lattice, and perhaps also > from the propositions as types formalism. The type that is properly > "absurd" is the type with no elements at all, corresponding to the empty > set. A functino returning a value of this type can never return, > because there are no values of that type. > > But since Modula 3 (as many other languages) has no truly empty type, > the bottom of the type lattice is NULL, and I suppose its kind of > plausible that it get called "absurd" for that reason. > > -- hendrik From rodney_bates at lcwb.coop Wed Apr 24 20:59:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Apr 2013 13:59:40 -0500 Subject: [M3devel] null type? In-Reply-To: <20130424030938.GA32407@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <20130424030938.GA32407@topoi.pooq.com> Message-ID: <51782B9C.9040701@lcwb.coop> The main intended use for NULL in Modula-3 is not to declare variables with it, but as an alternative label in a TYPECASE statement, for which it is extremely convenient. Otherwise, a NIL would always match the first alternative, which is often not what you want. Wrapping an IF v = NIL THEN ... ELSE TYPECASE v OF ... around it would work, but be more awkward to code. Even more so if v were an expression involving runtime computation that you really didn't want done twice, inviting yet another wrapping by a WITH construct. Somewhere in all the informal language description stuff, this is spelled out, but it might take a lot of time to find it. On 04/23/2013 10:09 PM, Hendrik Boom wrote: > On Mon, Apr 22, 2013 at 04:29:06PM -0700, Darko Volaric wrote: >> There's another aspect of the NULL type which should be considered here. >> NULL is the complement of REFANY. Just as REFANY is the ultimate ancestor >> of all reference types, NULL is the ultimate descendant of >> all reference types. As a result any variable of a reference type can be >> assigned NIL. Because of its unusual position, NIL is the only member of >> type NULL, since no other value makes sense (which is why it's sometimes >> called the "absurd" type). > > I think that terminology comes from the type lattice, and perhaps also > from the propositions as types formalism. The type that is properly > "absurd" is the type with no elements at all, corresponding to the empty > set. A functino returning a value of this type can never return, > because there are no values of that type. > > But since Modula 3 (as many other languages) has no truly empty type, > the bottom of the type lattice is NULL, and I suppose its kind of > plausible that it get called "absurd" for that reason. > > -- hendrik > From mika at async.caltech.edu Thu Apr 25 04:53:13 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 24 Apr 2013 19:53:13 -0700 Subject: [M3devel] null type? In-Reply-To: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> Message-ID: <20130425025313.1BCD71A207D@async.async.caltech.edu> Darko writes: > >--Apple-Mail-2--196294281 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=us-ascii > >I think the correct approach is to treat a variable declaration with a = >type NULL as an error. The correspondence to C would be void, but just = >void, not void*. What is the representation of the declaration "void = >x"? I'm guessing C doesn't allow that. It's not an error since there is precisely one legal value for such a variable, namely, NIL. That value can be inferred from the type without inspecting the variable. If you make it illegal to declare variables of type NULL you may have to go back and change various code generators that depend on it. There are types that are truly empty in Modula-3, and it is illegal to declare variables of those types (but not illegal to declare those types or to use them to construct other types), e.g., CONST A = 3; B = 1; TYPE T = [A..B]; VAR t : T; (* static error *) TYPE A = ARRAY T OF X; (* not an error *) etc. From darko at darko.org Thu Apr 25 05:11:17 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 20:11:17 -0700 Subject: [M3devel] null type? In-Reply-To: <20130425025313.1BCD71A207D@async.async.caltech.edu> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> Message-ID: <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> Probably not a good idea to make it illegal for backwards compatibility if you really think it's going to break things, so perhaps issue a warning instead. But besides providing a type for NIL it doesn't serve much purpose and I can't see anything being lost by outlawing it, eliminating the confusion with REFANY might be gained. Just because it's a valid bit of code doesn't mean it's not a bug. Looking at the code you can reasonably assume the author thought NIL was of type REFANY. It's a useless declaration unless it's trying to make some sort of point by being useless. It's a declaration to pass in one possible value which it's already assigned and which you can't change. On Apr 24, 2013, at 7:53 PM, mika at async.caltech.edu wrote: > Darko writes: >> >> --Apple-Mail-2--196294281 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/plain; >> charset=us-ascii >> >> I think the correct approach is to treat a variable declaration with a = >> type NULL as an error. The correspondence to C would be void, but just = >> void, not void*. What is the representation of the declaration "void = >> x"? I'm guessing C doesn't allow that. > > It's not an error since there is precisely one legal value for such a variable, > namely, NIL. That value can be inferred from the type without inspecting the > variable. > > If you make it illegal to declare variables of type NULL you may have to go > back and change various code generators that depend on it. > > There are types that are truly empty in Modula-3, and it is illegal to > declare variables of those types (but not illegal to declare those types > or to use them to construct other types), e.g., > > CONST > A = 3; > B = 1; > > TYPE > T = [A..B]; > > VAR > t : T; (* static error *) > > TYPE > A = ARRAY T OF X; (* not an error *) > > etc. From mika at async.caltech.edu Thu Apr 25 05:45:32 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 24 Apr 2013 20:45:32 -0700 Subject: [M3devel] null type? In-Reply-To: <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> Message-ID: <20130425034532.F2CD01A207D@async.async.caltech.edu> What is lost is some of the mathematical simplicity of the type system. A type is just a set of values. There is nothing odd about a type that can contain a single value. By your logic, we should outlaw declarations of variables of type [1..1] as well. Or variables of type { OK } (one-value enumerations). The upshot would be to require special-case code in programs that *generate* Modula-3 code to check for types of a single value and avoid those through some gyrations involving value substitutions. I can see how that could be a big hassle in some cases---it would require the aforementioned code generators to be able to perform value substitutions and possibly dead-code elimination. Mika Darko writes: >Probably not a good idea to make it illegal for backwards compatibility = >if you really think it's going to break things, so perhaps issue a = >warning instead. But besides providing a type for NIL it doesn't serve = >much purpose and I can't see anything being lost by outlawing it, = >eliminating the confusion with REFANY might be gained. > >Just because it's a valid bit of code doesn't mean it's not a bug. = >Looking at the code you can reasonably assume the author thought NIL was = >of type REFANY. It's a useless declaration unless it's trying to make = >some sort of point by being useless. It's a declaration to pass in one = >possible value which it's already assigned and which you can't change.=20= > > > >On Apr 24, 2013, at 7:53 PM, mika at async.caltech.edu wrote: > >> Darko writes: >>>=20 >>> --Apple-Mail-2--196294281 >>> Content-Transfer-Encoding: quoted-printable >>> Content-Type: text/plain; >>> charset=3Dus-ascii >>>=20 >>> I think the correct approach is to treat a variable declaration with = >a =3D >>> type NULL as an error. The correspondence to C would be void, but = >just =3D >>> void, not void*. What is the representation of the declaration "void = >=3D >>> x"? I'm guessing C doesn't allow that. >>=20 >> It's not an error since there is precisely one legal value for such a = >variable, >> namely, NIL. That value can be inferred from the type without = >inspecting the >> variable. >>=20 >> If you make it illegal to declare variables of type NULL you may have = >to go >> back and change various code generators that depend on it. >>=20 >> There are types that are truly empty in Modula-3, and it is illegal to >> declare variables of those types (but not illegal to declare those = >types >> or to use them to construct other types), e.g., >>=20 >> CONST >> A =3D 3; >> B =3D 1; >>=20 >> TYPE >> T =3D [A..B]; >>=20 >> VAR >> t : T; (* static error *) >>=20 >> TYPE >> A =3D ARRAY T OF X; (* not an error *) >>=20 >> etc. From darko at darko.org Thu Apr 25 06:06:32 2013 From: darko at darko.org (Darko) Date: Wed, 24 Apr 2013 21:06:32 -0700 Subject: [M3devel] null type? In-Reply-To: <20130425034532.F2CD01A207D@async.async.caltech.edu> References: , <51749A56.4070909@lcwb.coop>, , <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> Message-ID: You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. On Apr 24, 2013, at 8:45 PM, mika at async.caltech.edu wrote: > What is lost is some of the mathematical simplicity of the type system. > > A type is just a set of values. > > There is nothing odd about a type that can contain a single value. > > By your logic, we should outlaw declarations of variables of type [1..1] > as well. Or variables of type { OK } (one-value enumerations). > > The upshot would be to require special-case code in programs that > *generate* Modula-3 code to check for types of a single value > and avoid those through some gyrations involving value substitutions. > > I can see how that could be a big hassle in some cases---it would require > the aforementioned code generators to be able to perform value substitutions > and possibly dead-code elimination. > > Mika > > > > > Darko writes: >> Probably not a good idea to make it illegal for backwards compatibility = >> if you really think it's going to break things, so perhaps issue a = >> warning instead. But besides providing a type for NIL it doesn't serve = >> much purpose and I can't see anything being lost by outlawing it, = >> eliminating the confusion with REFANY might be gained. >> >> Just because it's a valid bit of code doesn't mean it's not a bug. = >> Looking at the code you can reasonably assume the author thought NIL was = >> of type REFANY. It's a useless declaration unless it's trying to make = >> some sort of point by being useless. It's a declaration to pass in one = >> possible value which it's already assigned and which you can't change.=20= >> >> >> >> On Apr 24, 2013, at 7:53 PM, mika at async.caltech.edu wrote: >> >>> Darko writes: >>>> =20 >>>> --Apple-Mail-2--196294281 >>>> Content-Transfer-Encoding: quoted-printable >>>> Content-Type: text/plain; >>>> charset=3Dus-ascii >>>> =20 >>>> I think the correct approach is to treat a variable declaration with = >> a =3D >>>> type NULL as an error. The correspondence to C would be void, but = >> just =3D >>>> void, not void*. What is the representation of the declaration "void = >> =3D >>>> x"? I'm guessing C doesn't allow that. >>> =20 >>> It's not an error since there is precisely one legal value for such a = >> variable, >>> namely, NIL. That value can be inferred from the type without = >> inspecting the >>> variable. >>> =20 >>> If you make it illegal to declare variables of type NULL you may have = >> to go >>> back and change various code generators that depend on it. >>> =20 >>> There are types that are truly empty in Modula-3, and it is illegal to >>> declare variables of those types (but not illegal to declare those = >> types >>> or to use them to construct other types), e.g., >>> =20 >>> CONST >>> A =3D 3; >>> B =3D 1; >>> =20 >>> TYPE >>> T =3D [A..B]; >>> =20 >>> VAR >>> t : T; (* static error *) >>> =20 >>> TYPE >>> A =3D ARRAY T OF X; (* not an error *) >>> =20 >>> etc. From dragisha at m3w.org Thu Apr 25 07:38:46 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 25 Apr 2013 07:38:46 +0200 Subject: [M3devel] Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>, , <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>, <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> Message-ID: Great idea! https://github.com/blog/674-introducing-organizations cm3 organization is already created on github, and also modula-3 exists. Ideas? -- Dragi?a Duri? dragisha at m3w.org On Apr 24, 2013, at 3:40 PM, Darko wrote: > There doesn't seem to be an option to add yourself as a collaborator to that repository. Can we open a "cm3" organization account for the final repository? > > > On Apr 24, 2013, at 5:16 AM, Dragi?a Duri? wrote: > >> I don't know, really. Have you tried? >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> >> On Apr 24, 2013, at 1:52 PM, Darko wrote: >> >>> Is there no way for us to sign up as collaborators ourselves and be approved? >>> >>> >>> On Apr 23, 2013, at 11:50 PM, Dragi?a Duri? wrote: >>> >>>> I only checked Windows tools now, and found this: http://windows.github.com/ >>>> >>>> There is also github for Mac. >>>> >>>> On Unix/Linux it is native. >>>> >>>> For this repository, I will probably need to add Collaborators. Please pm me with your github username and I will add you (and of course everybody else from m3devel). >>>> >>>> dd >>>> >>>> On Apr 24, 2013, at 7:55 AM, Dragi?a Duri? wrote: >>>> >>>>> I never used perforce, I am a SVN user for 10+ yrs. There are lots of excellent tutorial for git, for example starting from here: http://sixrevisions.com/resources/git-tutorials-beginners/ >>>>> >>>>> I've used githowto.com some time ago. Looks great. >>>>> >>>>> It is no problem for me to repeat whole process, till this gets traction, but I think this is complete already. Please check with your workflow - just pull it and make. >>>>> >>>>> dd >>>>> -- >>>>> Dragi?a Duri? >>>>> dragisha at m3w.org >>>>> >>>>> >>>>> >>>>> On Apr 23, 2013, at 11:37 PM, Jay K wrote: >>>>> >>>>>> I have pretty much never used git or svn. I learn new source control systems kinda slowly. >>>>>> I need small clear directions, in terms of systems I already use, perforce or cvs, preferably perforce since it is excellent. >>>>>> >>>>>> Thank you, >>>>>> - Jay >>>>>> >>>>>> From: dragisha at m3w.org >>>>>> Date: Tue, 23 Apr 2013 07:24:11 +0200 >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] Trial conversion(s) >>>>>> >>>>>> Anybody had a look at final conversion? Jay? >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>>> >>>>>> >>>>>> >>>>>> On Apr 22, 2013, at 8:46 AM, Dragi?a Duri? wrote: >>>>>> >>>>>> http://pastebin.com/pWvsYqdj >>>>>> >>>>>> Tags converted, in final phase. All comments, changesets. Came before, during conversion process on my computer. >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>>> >>>>>> >>>>>> >>>>>> On Apr 22, 2013, at 12:45 AM, Dragi?a Duri? wrote: >>>>>> >>>>>> https://github.com/dragisha/cm3 >>>>>> >>>>>> Please check if it is ok, whoever has time/will. >>>>>> >>>>>> Please keep in mind this is preliminary. >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>>> >>>>>> >>>>>> >>>>>> On Apr 21, 2013, at 10:19 PM, Dragi?a Duri? wrote: >>>>>> >>>>>> I did few cvs2svn conversions, found few trivial problems in cm3 CVS repo, and configured resulting svn with my trac, and everything went well. >>>>>> >>>>>> Today I created cm3 github repo. I am new to github, and I know elementary things about git, so I am doing a trial conversion/initialization first. >>>>>> >>>>>> First git to make will be local, so I can compare to full checkout from our CVS. I have local (maintained by CVSup) CVS mirror, but I also did a "tar czf" and copied it, just to be 100% sure I have what is on server. >>>>>> >>>>>> Report tomorrow, or so :) >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> dragisha at m3w.org >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Apr 25 08:34:13 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 25 Apr 2013 08:34:13 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> Message-ID: <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> On Thu, 25 Apr 2013 07:38:46 +0200 Dragi?a Duri? wrote: > Great idea! > > https://github.com/blog/674-introducing-organizations > > cm3 organization is already created on github, and also modula-3 exists. Ideas? I think the most important question we need to answer first is if and how we should split up the CM3 repository into several smaller ones, i.e. factor out standalone applications and projects like ESC, caltech-parser, m3lectern, m3gdb, etc. I'm not sure if we can do this easily later with git. I'd also like to see some performance numbers for a complete clone and checkout, as this is what several of the regression test jobs will do. Of course the latter can be done based on a local slave repository. I've created a Wiki page to document the migration project in trac at https://cm3-bugs.elegosoft.com/cm3/wiki/CvsToGitMigration I'd like to encourage everybody to add their ideas and notes there. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu Apr 25 08:51:34 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 25 Apr 2013 08:51:34 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> Message-ID: <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository It looks to me it is thought of in git? Maybe it is not a current priority? -- Dragi?a Duri? dragisha at m3w.org On Apr 25, 2013, at 8:34 AM, Olaf Wagner wrote: > I think the most important question we need to answer first is if and how > we should split up the CM3 repository into several smaller ones, i.e. > factor out standalone applications and projects like ESC, caltech-parser, > m3lectern, m3gdb, etc. > > I'm not sure if we can do this easily later with git. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Thu Apr 25 09:27:40 2013 From: wagner at elego.de (Olaf Wagner) Date: Thu, 25 Apr 2013 09:27:40 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> Message-ID: <20130425092740.55bf536a.wagner@elego.de> On Thu, 25 Apr 2013 08:51:34 +0200 Dragi?a Duri? wrote: > http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository > > It looks to me it is thought of in git? Maybe it is not a current priority? Well, that's something I didn't know about. However, since we need to setup the regression testing anew, or better, move from Hudson to Jenkins at the same time, it may be better to split before we do that. Are there any strong opinions about such a move? Olaf > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 25, 2013, at 8:34 AM, Olaf Wagner wrote: > > > I think the most important question we need to answer first is if and how > > we should split up the CM3 repository into several smaller ones, i.e. > > factor out standalone applications and projects like ESC, caltech-parser, > > m3lectern, m3gdb, etc. > > > > I'm not sure if we can do this easily later with git. > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Thu Apr 25 10:52:03 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 25 Apr 2013 10:52:03 +0200 Subject: [M3devel] CM3 CVS to GIT conversion, was: Re: Trial conversion(s) In-Reply-To: <20130425092740.55bf536a.wagner@elego.de> References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org> <2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org> <60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org> <234B341B-3829-4627-8F4F-540D54D6B915@m3w.org> <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com> <743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org> <20130425092740.55bf536a.wagner@elego.de> Message-ID: On Apr 25, 2013, at 9:27 AM, Olaf Wagner wrote: >> >> http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository >> >> It looks to me it is thought of in git? Maybe it is not a current priority? > > Well, that's something I didn't know about. However, since we need to setup > the regression testing anew, or better, move from Hudson to Jenkins at the > same time, it may be better to split before we do that. > > Are there any strong opinions about such a move? Does a strong support count? :) Also: http://stackoverflow.com/questions/3910412/split-large-git-repository-into-many-smaller-ones So, yes? We can do it in multiple ways. > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Apr 25 15:20:12 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Apr 2013 09:20:12 -0400 Subject: [M3devel] null type? In-Reply-To: References: <51749A56.4070909@lcwb.coop> <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> Message-ID: <20130425132012.GA28811@topoi.pooq.com> On Wed, Apr 24, 2013 at 09:06:32PM -0700, Darko wrote: > You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. > > The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. > > Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. Could the problem be just with NULL-typed variables where the NULL type is not mentioned explicitly in the declaration? These might merit a warning. By the way, what is done with VAR x := 1; Is x implicitly of type 1:1? -- hendrik From rodney_bates at lcwb.coop Thu Apr 25 19:36:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Apr 2013 12:36:11 -0500 Subject: [M3devel] null type? In-Reply-To: <20130425132012.GA28811@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> Message-ID: <5179698B.7020703@lcwb.coop> On 04/25/2013 08:20 AM, Hendrik Boom wrote: > On Wed, Apr 24, 2013 at 09:06:32PM -0700, Darko wrote: >> You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. >> >> The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. >> >> Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. > > Could the problem be just with NULL-typed variables where the NULL type > is not mentioned explicitly in the declaration? > > These might merit a warning. > > By the way, what is done with > VAR x := 1; > No, the type of 1 is INTEGER, and the type of 1L is LONGINT. But you could make something like that happen with CONST OneOnly : [1..1] = 1; VAR x := OneOnly; > Is x implicitly of type 1:1? > > -- hendrik > From rodney_bates at lcwb.coop Thu Apr 25 19:37:38 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Apr 2013 12:37:38 -0500 Subject: [M3devel] null type? In-Reply-To: <20130425132012.GA28811@topoi.pooq.com> References: <51749A56.4070909@lcwb.coop> <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> Message-ID: <517969E2.8000702@lcwb.coop> On 04/25/2013 08:20 AM, Hendrik Boom wrote: > On Wed, Apr 24, 2013 at 09:06:32PM -0700, Darko wrote: >> You're wrongly suggesting I object to single valued to single value types. Read what I wrote, there's no such implication or logic since I'm discussing a special case. What I object to is the confusion created by allowing the use of the NULL typed variables in particular, evidenced by the error. It's not any more difficult to outlaw variables of NULL anymore than it is to outlaw the use of empty types. >> >> The type system and its mathematical simplicity is not affected by what the compiler deems acceptable, you still have the NULL type defined as before. The issue is acceptable variable declarations. >> >> Anyway, it's an idea. If you don't like it ignore it. If someone threatens to implement it, take it up with them, I'm sure they'll enjoy the discussion. > > Could the problem be just with NULL-typed variables where the NULL type > is not mentioned explicitly in the declaration? > > These might merit a warning. > > By the way, what is done with > VAR x := 1; > No, the type of 1 is INTEGER (and the type of 1L is LONGINT). see 2.6.4. But you could make something like that happen with CONST OneOnly : [1..1] = 1; VAR x := OneOnly; > Is x implicitly of type 1:1? > > -- hendrik > From hendrik at topoi.pooq.com Thu Apr 25 20:13:03 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Apr 2013 14:13:03 -0400 Subject: [M3devel] UI libraries Message-ID: <20130425181303.GA31005@topoi.pooq.com> Are there bindings for Modula 3 to use user-interface libraries other than Trestle? If so, are any of those libraries cross-platform? If not, would it be worth writing such a binding? And for which library? -- hendrik From hendrik at topoi.pooq.com Thu Apr 25 20:16:02 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Apr 2013 14:16:02 -0400 Subject: [M3devel] null type? In-Reply-To: <5179698B.7020703@lcwb.coop> References: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> <5179698B.7020703@lcwb.coop> Message-ID: <20130425181602.GB31005@topoi.pooq.com> On Thu, Apr 25, 2013 at 12:36:11PM -0500, Rodney M. Bates wrote: > > > On 04/25/2013 08:20 AM, Hendrik Boom wrote: > > > >Could the problem be just with NULL-typed variables where the NULL type > >is not mentioned explicitly in the declaration? > > > >These might merit a warning. > > > >By the way, what is done with > > VAR x := 1; > > > > No, the type of 1 is INTEGER, and the type of 1L is LONGINT. > > But you could make something like that happen with > CONST OneOnly : [1..1] = 1; > VAR x := OneOnly; Is there some reason why 1 is by default given the maximal type containing 1, whereas NIL is given the minimal type containing NIL? -- hendrik > > >Is x implicitly of type 1:1? > > > >-- hendrik > > > From dmuysers at hotmail.com Thu Apr 25 22:12:23 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Thu, 25 Apr 2013 22:12:23 +0200 Subject: [M3devel] UI libraries In-Reply-To: <20130425181303.GA31005@topoi.pooq.com> References: <20130425181303.GA31005@topoi.pooq.com> Message-ID: If I had the time, I would opt for the IUP portable interface library (http://www.tecgraf.puc-rio.br/iup/) Bindings for that one are particularly easy to make. Only drawback: The next release will implement UTF-8 text for all platforms (the existing version has ASCII for Win32 and UTF-8 for GTK). I would myself like M3 to step back to the good old SRC-PM3 text system (but UTF-8 encoded) preferably to the actual dual CHAR-WCHAR text machinery). I also think that it was Microsoft's biggest mistake to impose 16-bit characters which are still variable length (think of surrogates) without the advantages UTF-8 offers. -------------------------------------------------- From: "Hendrik Boom" Sent: Thursday, April 25, 2013 8:13 PM To: Subject: [M3devel] UI libraries > Are there bindings for Modula 3 to use user-interface libraries other > than Trestle? > > If so, are any of those libraries cross-platform? > > If not, would it be worth writing such a binding? And for which library? > > -- hendrik From rodney_bates at lcwb.coop Thu Apr 25 22:20:02 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Apr 2013 15:20:02 -0500 Subject: [M3devel] null type? In-Reply-To: <20130425181602.GB31005@topoi.pooq.com> References: <49760236-BC90-4CD3-8A62-389FF6A57617@darko.org> <20130425025313.1BCD71A207D@async.async.caltech.edu> <21BBC461-20A3-4D1E-8401-9F9863D126CA@darko.org> <20130425034532.F2CD01A207D@async.async.caltech.edu> <20130425132012.GA28811@topoi.pooq.com> <5179698B.7020703@lcwb.coop> <20130425181602.GB31005@topoi.pooq.com> Message-ID: <51798FF2.8020302@lcwb.coop> On 04/25/2013 01:16 PM, Hendrik Boom wrote: > On Thu, Apr 25, 2013 at 12:36:11PM -0500, Rodney M. Bates wrote: >> >> >> On 04/25/2013 08:20 AM, Hendrik Boom wrote: >>> >>> Could the problem be just with NULL-typed variables where the NULL type >>> is not mentioned explicitly in the declaration? >>> >>> These might merit a warning. >>> >>> By the way, what is done with >>> VAR x := 1; >>> >> >> No, the type of 1 is INTEGER, and the type of 1L is LONGINT. >> >> But you could make something like that happen with >> CONST OneOnly : [1..1] = 1; >> VAR x := OneOnly; > > Is there some reason why 1 is by default given the maximal type > containing 1, whereas NIL is given the minimal type containing NIL? Hmm, that's a good question. I'm just speculating here, but I can think of a couple of things. There is just one NULL in the language, and it is builtin and the same minimum for all reference types, traced and untraced. In contrast, every integer (and enumeration) literal value would have a different minimal type, and these are not builtin types. They would all be implicitly defined by their literal values, creating a lot of stuff floating around the compiler that wouldn't do much, since they would all be statically assignable, wherever referenced. As for making NIL have maximal type, there isn't one in the language now. It would have to include both the traced and untraced hierarchies. Then somebody could declare a variable of that type, giving a need to be able to distinguish the non-NIL values at runtime as traced or not. That would either call for some kind of fat pointer (which there would not be enough bits, in case of UNTRACED REF CHAR) or having every referent have a heap allocator word, which would then undermine using untraced refs for unsafe low-level coding like pointers to things not in any heap. I suppose there could have been separate traced and untraced NILs, but that probably would have gotten major complaints and been much harder to justify than say, 1 vs. 1L, which are necessary for resolution of arithmetic operators. > > -- hendrik > >> >>> Is x implicitly of type 1:1? >>> >>> -- hendrik >>> >> > From dragisha at m3w.org Fri Apr 26 08:08:55 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 26 Apr 2013 08:08:55 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: References: <20130425181303.GA31005@topoi.pooq.com> Message-ID: <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> As for GUI, I have pretty extensive binding for Gtk+, and I am also done some work with gobject-introspection with plans to provide complete binding of everything glib. My plan is to publish it (an older version, for Gtk1, already circulated here). Gtk+ works on almost everything. As for TEXT system? Old TEXT system base type was semiopaque REF ARRAY OF CHAR. Compiler was hooking & to Text.Cat which was "allocate enough space, copy both arguments, keep everything ASCIIZ". New type makes & as efficient as possible, but does not disallow us to reimplement RtHooks' Cat and MultiCat to behave just like 3.6/pm3 Text.Cat. I think cm3's reasoning was pretty natural once they decided (because of task at hand, JVM) to create WIDECHAR as standard type. Next was W"" literal, and one thing was following another. When this proved itself as efficient for their needs, it was cemented. I would like to know if anybody would object to reimplementation of TextCat module? I can make it, no problem, as people are not going to lynch me :). Dirk, are you covering Unicode Collate with your Unicode implementation? Except for Unicode tables (and your earlier implementation of this is very useful) and UTF handling/operations (I have this, very complete), Unicode Collate remain biggest remaining obstacle for full incorporation of Unicode/UTF8 into cm3. dd On Apr 25, 2013, at 10:12 PM, Dirk Muysers wrote: > I would myself like M3 to step back to the good old > SRC-PM3 text system (but UTF-8 encoded) > preferably to the actual dual CHAR-WCHAR text > machinery). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri Apr 26 11:17:59 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Fri, 26 Apr 2013 11:17:59 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> Message-ID: >> Dirk, are you covering Unicode Collate with your Unicode implementation? Except for Unicode >> tables (and your earlier implementation of this is very useful) and UTF handling/operations >> (I have this, very complete), Unicode Collate remain biggest remaining obstacle for full incorporation >> of Unicode/UTF8 into cm3. Full Unicode collation implies normalization and a lot more tables (and tools to extract these tables from the Unicode data base) The only libraries I know about that do it are the (rather monstruous) IBM library and, to a certain extent, glib. Even go(lang) doesn't offer it. Normal comparison associated with simple case folding (which is part of my library) is a first step in that direction. Simple case folding folds only 1:1 UC/LC pairs. The emblematic special case being German eszet that folds to SS, but even that case is now covered by the inclusion of a special eszet upper case glyph in recent Unicode releases, so that most European languages are now covered. Languages that still need special processing are the Turkic family (Turkish and Azeri). So, as long as one compares only own text files (which do not mingle accented glyphs and decomposed glyphs), one gets an acceptable collation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 26 21:37:18 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 26 Apr 2013 14:37:18 -0500 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> Message-ID: <517AD76E.9090007@lcwb.coop> On 04/26/2013 01:08 AM, Dragi?a Duri? wrote: > As for GUI, I have pretty extensive binding for Gtk+, and I am also done some work with gobject-introspection with plans to provide complete binding of everything glib. My plan is to publish it (an older version, for Gtk1, already circulated here). Gtk+ works on almost everything. > > As for TEXT system? Old TEXT system base type was semiopaque REF ARRAY OF CHAR. Compiler was hooking & to Text.Cat which was "allocate enough space, copy both arguments, keep everything ASCIIZ". New type makes & as efficient as possible, but does not disallow us to reimplement RtHooks' Cat and MultiCat to behave just like 3.6/pm3 Text.Cat. > Two or three years ago, I wrote a revised system that lies somewhere between the compromises of PM3 and CM3 Text operations. It uses the same data structure and invariants as the CM3 system, so any values it produces are consistent with existing CM3-compiled code. It partially flattens concatenated strings, as in PM3, up to a point. It also does some heuristic approximate rebalancing of concatenated trees. Between these, it achieves some significant performance advantages, though it loses some in certain cases. Both the PM3 and the CM3 system have performance problems when a Text is built up linearly, left-to-right (or right-to-left) from single characters or short fragments. This is a very common pattern. PM3 makes concatenation O(N), but accessing is O(1). CM3 is the opposite. Concatenation is O(1) but O(N) in accessing individual characters and substrings. CM3 also uses somewhere around an order of magnitude more memory for linearly-concatenated strings. I posted a bunch of empirical performance numbers on this list, showing some of the tradeoffs of my intermediate implementation. I think it would represent a good middle ground. Barring that, I too would go back to the PM3 scheme, as the storage use and access time of the original CM3 scheme can be pretty awful. It never got put into the repository because I had the means to test only for LINUXLIBC6 and AMD64_LINUX. It is pretty thoroughly tested on those platforms. It's hard to imagine target-dependent bugs, but who hasn't been wrong about that before? Perhaps we could get its test program into the automated system on the many platforms, then consider using it. > I think cm3's reasoning was pretty natural once they decided (because of task at hand, JVM) to create WIDECHAR as standard type. Next was W"" literal, and one thing was following another. When this proved itself as efficient for their needs, it was cemented. > > I would like to know if anybody would object to reimplementation of TextCat module? I can make it, no problem, as people are not going to lynch me :). > > Dirk, are you covering Unicode Collate with your Unicode implementation? Except for Unicode tables (and your earlier implementation of this is very useful) and UTF handling/operations (I have this, very complete), Unicode Collate remain biggest remaining obstacle for full incorporation of Unicode/UTF8 into cm3. > > dd > > On Apr 25, 2013, at 10:12 PM, Dirk Muysers wrote: > >> I would myself like M3 to step back to the good old >> SRC-PM3 text system (but UTF-8 encoded) >> preferably to the actual dual CHAR-WCHAR text >> machinery). > From dragisha at m3w.org Fri Apr 26 23:21:59 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 26 Apr 2013 23:21:59 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <517AD76E.9090007@lcwb.coop> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> <517AD76E.9090007@lcwb.coop> Message-ID: <3B35444C-3155-41E4-9714-F39DC5BFF1CD@m3w.org> Original PM3 scheme is a bit too much back :), being non OO. Objectness of TEXT has its uses. I think your scheme can be incorporated as an alternative, selectable during m3core build, without much problem. I would like to try it. On Apr 26, 2013, at 9:37 PM, Rodney M. Bates wrote: > I posted a bunch of empirical performance numbers on this list, showing some of the tradeoffs > of my intermediate implementation. I think it would represent a good middle ground. Barring > that, I too would go back to the PM3 scheme, as the storage use and access time of the original > CM3 scheme can be pretty awful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 26 23:49:39 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 26 Apr 2013 23:49:39 +0200 Subject: [M3devel] UI libraries (also WIDECHAR/cm3 TEXT) In-Reply-To: <3B35444C-3155-41E4-9714-F39DC5BFF1CD@m3w.org> References: <20130425181303.GA31005@topoi.pooq.com> <3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org> <517AD76E.9090007@lcwb.coop> <3B35444C-3155-41E4-9714-F39DC5BFF1CD@m3w.org> Message-ID: <20130426234939.60d0f292b878b9e65b98441b@elegosoft.com> On Fri, 26 Apr 2013 23:21:59 +0200 Dragi?a Duri? wrote: > Original PM3 scheme is a bit too much back :), being non OO. Objectness of TEXT has its uses. > > I think your scheme can be incorporated as an alternative, selectable during m3core build, without much problem. I would like to try it. I'd also vote to give Rodney's code a try. Olaf > On Apr 26, 2013, at 9:37 PM, Rodney M. Bates wrote: > > > I posted a bunch of empirical performance numbers on this list, showing some of the tradeoffs > > of my intermediate implementation. I think it would represent a good middle ground. Barring > > that, I too would go back to the PM3 scheme, as the storage use and access time of the original > > CM3 scheme can be pretty awful. -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sun Apr 28 20:09:32 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 28 Apr 2013 20:09:32 +0200 Subject: [M3devel] Issues with gcc backend optimizations, any? Message-ID: I remember we had issues with optimizations turned on. Is it safe to use now? -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Sun Apr 28 23:03:30 2013 From: jay.krell at cornell.edu (Jay) Date: Sun, 28 Apr 2013 14:03:30 -0700 Subject: [M3devel] configure_system_libs In-Reply-To: <20130428190606.3DF769BA007@birch.elegosoft.com> References: <20130428190606.3DF769BA007@birch.elegosoft.com> Message-ID: I probably handle this in cm3.cfg. But you are probably mixing new tree with old config... - Jay On Apr 28, 2013, at 2:06 PM, "Rodney M. Bates" wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/04/28 21:06:06 > > Modified files: > cm3/m3-db/odbc/test/src/: m3makefile > ./: m3makefile > cm3/m3-db/pgodbc/src/: m3makefile > ./: m3makefile > cm3/m3-db/postgres95/test/src/: m3makefile > ./: m3makefile > cm3/m3-games/columns/src-x11/: m3makefile > ./: m3makefile > cm3/m3-games/tetris/src/: m3makefile > ./: m3makefile > cm3/m3-tools/cvsup/suplib/src/: m3makefile > ./: m3makefile > cm3/m3-tools/gnuemacs/src/: m3makefile > ./: m3makefile > cm3/m3-tools/pp/src/: m3makefile > ./: m3makefile > cm3/m3-ui/PEX/src/: m3makefile > ./: m3makefile > cm3/m3-ui/X11R4/src/: m3makefile > ./: m3makefile > cm3/m3-ui/anim3D/src/: m3makefile > ./: m3makefile > cm3/m3-ui/motif/src/: m3makefile > ./: m3makefile > cm3/m3-ui/opengl/src/: m3makefile > ./: m3makefile > cm3/m3-ui/ui/src/xvbt/: m3makefile > > Log message: > Many packages were failing to build, with: > > quake runtime error: undefined variable: configure_system_libs > > at least on LINUXLIBC6. Make the call on configure_system_libs in these > m3makefiles conditional on its being defined, as they already were in the > m3makefiles in several other packages. > From dragisha at m3w.org Tue Apr 30 07:42:44 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 30 Apr 2013 07:42:44 +0200 Subject: [M3devel] thread local storage, but in C pieces of runtime... (jay, tony?) Message-ID: <8489B8D9-9442-4EE1-940F-4C69B96AF61B@m3w.org> Is there a specific reason why TLS is done through C, and not through pthread.(set|get)specific? dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hosking at cs.purdue.edu Tue Apr 30 09:21:50 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 30 Apr 2013 17:21:50 +1000 Subject: [M3devel] thread local storage, but in C pieces of runtime... (jay, tony?) In-Reply-To: <8489B8D9-9442-4EE1-940F-4C69B96AF61B@m3w.org> References: <8489B8D9-9442-4EE1-940F-4C69B96AF61B@m3w.org> Message-ID: <80EA00C3-AACC-472D-A43B-E2121CBD4AAB@cs.purdue.edu> I used to use pthread specifics but I think jay changed it to C. Not sure why unless compiler can generate more efficiently via sp hacks. Sent from my iPhone On 30/04/2013, at 3:42 PM, Dragi?a Duri? wrote: > Is there a specific reason why TLS is done through C, and not through pthread.(set|get)specific? > > dd > > -- > Dragi?a Duri? > dragisha at m3w.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 30 09:23:17 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 30 Apr 2013 17:23:17 +1000 Subject: [M3devel] Fwd: thread local storage, but in C pieces of runtime... (jay, tony?) References: <80EA00C3-AACC-472D-A43B-E2121CBD4AAB@cs.purdue.edu> Message-ID: <695CFD6E-FE05-4CAC-99DD-18D8B5CCCE26@cs.purdue.edu> Sent from my iPhone Begin forwarded message: > From: Tony Hosking > Date: 30 April 2013 5:21:50 PM AEST > To: Dragi?a Duri? > Cc: m3devel developers > Subject: Re: [M3devel] thread local storage, but in C pieces of runtime... (jay, tony?) > > I used to use pthread specifics but I think jay changed it to C. Not sure why unless compiler can generate more efficiently via sp hacks. > > Sent from my iPhone > > On 30/04/2013, at 3:42 PM, Dragi?a Duri? wrote: > >> Is there a specific reason why TLS is done through C, and not through pthread.(set|get)specific? >> >> dd >> >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 30 17:43:50 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 30 Apr 2013 10:43:50 -0500 Subject: [M3devel] configure_system_libs In-Reply-To: References: <20130428190606.3DF769BA007@birch.elegosoft.com> Message-ID: <517FE6B6.2020809@lcwb.coop> On 04/28/2013 04:03 PM, Jay wrote: > I probably handle this in cm3.cfg. > But you are probably mixing new tree with old config... > > I am building a freshly-updated head, using the most recent release, without modification, to do it. That should always work. > - Jay > > On Apr 28, 2013, at 2:06 PM, "Rodney M. Bates" wrote: > >> CVSROOT: /usr/cvs >> Changes by: rodney at birch. 13/04/28 21:06:06 >> >> Modified files: >> cm3/m3-db/odbc/test/src/: m3makefile >> ./: m3makefile >> cm3/m3-db/pgodbc/src/: m3makefile >> ./: m3makefile >> cm3/m3-db/postgres95/test/src/: m3makefile >> ./: m3makefile >> cm3/m3-games/columns/src-x11/: m3makefile >> ./: m3makefile >> cm3/m3-games/tetris/src/: m3makefile >> ./: m3makefile >> cm3/m3-tools/cvsup/suplib/src/: m3makefile >> ./: m3makefile >> cm3/m3-tools/gnuemacs/src/: m3makefile >> ./: m3makefile >> cm3/m3-tools/pp/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/PEX/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/X11R4/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/anim3D/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/motif/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/opengl/src/: m3makefile >> ./: m3makefile >> cm3/m3-ui/ui/src/xvbt/: m3makefile >> >> Log message: >> Many packages were failing to build, with: >> >> quake runtime error: undefined variable: configure_system_libs >> >> at least on LINUXLIBC6. Make the call on configure_system_libs in these >> m3makefiles conditional on its being defined, as they already were in the >> m3makefiles in several other packages. >> > From darko at darko.org Mon Apr 1 23:53:37 2013 From: darko at darko.org (Darko) Date: Mon, 1 Apr 2013 14:53:37 -0700 Subject: [M3devel] Why do we need external debugging? Message-ID: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko From dabenavidesd at yahoo.es Tue Apr 2 05:42:39 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 2 Apr 2013 04:42:39 +0100 (BST) Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <1364874159.80556.YahooMailClassic@web172803.mail.ir2.yahoo.com> Hi all: yes, the VAX900 mainframe had this capability, of executing the code an same time verifying its operation results. Would like to make a RT in that way, but it shouldn't be that hard, should be? Thanks in advance PS: BTW I just had an idea today, make the experiment in DEC-SRC of DISPOSABLE memory information safe, so making some adjustments to the type system, with coercion and other soft typing stuff make the language type safe entirely, We would need just suppress the annoying word UNSAFE of all modules, and make the language 100% machine checkable. At the same time introducing functional objects, like in bay Modula-3 , to able to model the language in that way. Thanks in advance --- El lun, 1/4/13, Darko escribi?: De: Darko Asunto: [M3devel] Why do we need external debugging? Para: "m3devel developers" Fecha: lunes, 1 de abril, 2013 16:53 The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Apr 2 06:02:15 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 2 Apr 2013 05:02:15 +0100 (BST) Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1364874159.80556.YahooMailClassic@web172803.mail.ir2.yahoo.com> Message-ID: <1364875335.9036.YahooMailClassic@web172805.mail.ir2.yahoo.com> Hi all: an old known in this list wrote me today precisely about need of source level debuggers and builtin-debuggers in MacApp API in Pascal years: ? http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2013/3/30_Building_Photoshop.html read the last and before last paragraph (sounds like we would need language modification to support this kind of debugger) Thanks in advance --- El lun, 1/4/13, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] Why do we need external debugging? Para: "m3devel developers" , "Darko" Fecha: lunes, 1 de abril, 2013 22:42 Hi all: yes, the VAX900 mainframe had this capability, of executing the code an same time verifying its operation results. Would like to make a RT in that way, but it shouldn't be that hard, should be? Thanks in advance PS: BTW I just had an idea today, make the experiment in DEC-SRC of DISPOSABLE memory information safe, so making some adjustments to the type system, with coercion and other soft typing stuff make the language type safe entirely, We would need just suppress the annoying word UNSAFE of all modules, and make the language 100% machine checkable. At the same time introducing functional objects, like in bay Modula-3 , to able to model the language in that way. Thanks in advance --- El lun, 1/4/13, Darko escribi?: De: Darko Asunto: [M3devel] Why do we need external debugging? Para: "m3devel developers" Fecha: lunes, 1 de abril, 2013 16:53 The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. Am I the only one who thinks this? - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 2 06:22:12 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Apr 2013 04:22:12 +0000 Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: External debuggers are good. Have you used Visual Studio much? Generate the right debug information and we get excellent working debuggers that people put a lot of time and work into. On the other hand, I do understand your notion of "internal debugger" and agree it is a good approach. - Jay > From: darko at darko.org > Date: Mon, 1 Apr 2013 14:53:37 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Why do we need external debugging? > > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > Am I the only one who thinks this? > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Apr 2 06:44:02 2013 From: darko at darko.org (Darko) Date: Mon, 1 Apr 2013 21:44:02 -0700 Subject: [M3devel] Why do we need external debugging? In-Reply-To: References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: Can't say I like VS, though I have used it. I didn't really use any of the features except the stack dump. For a language like M3 internal debugging makes a lot of sense since it's unlikely to affect anything else, and I like the idea of being able to customize it for my own purposes while maintaining performance. Maybe a simple object based "plug in" architecture would work well. On Apr 1, 2013, at 9:22 PM, Jay K wrote: > External debuggers are good. Have you used Visual Studio much? > Generate the right debug information and we get excellent working debuggers that people put a lot of time and work into. > > > On the other hand, I do understand your notion of "internal debugger" and agree it is a good approach. > > > - Jay > > > > > From: darko at darko.org > > Date: Mon, 1 Apr 2013 14:53:37 -0700 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Why do we need external debugging? > > > > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > > > Am I the only one who thinks this? > > > > - Darko > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 2 15:08:26 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 2 Apr 2013 09:08:26 -0400 Subject: [M3devel] Why do we need external debugging? In-Reply-To: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <20130402130826.GB16617@topoi.pooq.com> On Mon, Apr 01, 2013 at 02:53:37PM -0700, Darko wrote: > The last time I used an external or lowish-level debugger was the last time I programmed in a language other than M3. I find the language so safe and reliable that I don't quite understand the need for external debuggers. Is it driven by a need to integrate with other languages or external libraries? > > Why can't a debugger be optionally compiled into the code and supported by the runtime? I find I don't need much more than the ability to log procedure execution, procedure parameters and local variables. I imagine some sort of debugging mode with a simple command line and an interrupt mechanism would facilitate interactive debugging. > > Am I the only one who thinks this? Internal debuggers are great for programs that are written all in one language. But not so great when multiple languages are involved. Unfortunately, the debuggers we have don't seem to have evolved to exhibit the interfaces needed for source languages significantly different from C. C-- has primitives for stack-walking, on which a debugging-style stack-walker could be built, but even here there's no canonical way to provide variable-name information and the like. -- hendrik From darko at darko.org Tue Apr 2 19:51:48 2013 From: darko at darko.org (Darko) Date: Tue, 2 Apr 2013 10:51:48 -0700 Subject: [M3devel] Internal debugging - a simple design Message-ID: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Here's an idea for how simple internal debugging might work. A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): CONST ProcName: TEXT = "Module.ProcName"; ProcType: CARDINAL = 12345678; ProcAdr: ADDRESS = 123456; ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); ReturnType: CARDINAL = 12345678; ReturnOffs: INTEGER = 32; LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: PROCEDURE DebugProcEntry( READONLY frame: ADDRESS; READONLY procName: ProcName; READONLY procType: ProcType; READONLY procAdr: ProcAdr; READONLY paramNames: ParamNames; READONLY paramTypes: ParamTypes; READONLY paramOffs: ParamOffs; READONLY returnType: ReturnType; READONLY returnOffs: ReturnOffs; READONLY localNames: LocalNames; READONLY localTypes: LocalTypes; READONLY localOffs: LocalOffs ); Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. - Darko From jay.krell at cornell.edu Wed Apr 3 00:39:09 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Apr 2013 22:39:09 +0000 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Message-ID: I don't want to have to recompile anything. Ideally the overhead of the debug stuff is low enough that it is always on. That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. I believe you need to make a function call for every line or "instruction". That is the hook for stepping and breakpoints. You need function calls to the debugger for every assignment. If you have something like "watch breakpoints" ("Break whenv variable x becomes 123.") On the assignment matter though, it could be done in the step/instruction call. There isn't necessarily a zero offset for parameters and locals.. well..a debug system probably creates one..homing all the parameters and not enregistering everything..You should probably bundle up the data into a smaller number of linked structures, in order to pass fewer parameters to DebugProcEntry. Beware module globals also. Even in my upcoming C backend work, they don't work well. I think that needs frontend work. :( - Jay > From: darko at darko.org > Date: Tue, 2 Apr 2013 10:51:48 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Internal debugging - a simple design > > Here's an idea for how simple internal debugging might work. > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > CONST > ProcName: TEXT = "Module.ProcName"; > ProcType: CARDINAL = 12345678; > ProcAdr: ADDRESS = 123456; > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > ReturnType: CARDINAL = 12345678; > ReturnOffs: INTEGER = 32; > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > PROCEDURE DebugProcEntry( > READONLY frame: ADDRESS; > READONLY procName: ProcName; > READONLY procType: ProcType; > READONLY procAdr: ProcAdr; > READONLY paramNames: ParamNames; > READONLY paramTypes: ParamTypes; > READONLY paramOffs: ParamOffs; > READONLY returnType: ReturnType; > READONLY returnOffs: ReturnOffs; > READONLY localNames: LocalNames; > READONLY localTypes: LocalTypes; > READONLY localOffs: LocalOffs > ); > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 3 02:45:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 00:45:23 +0000 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> , <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> Message-ID: > along with a special number for registers and pesudo-functions I missed that, sorry, by skimming. Be sure to use very large but not negative numbers..as negative numbersmight be actual offsets.. > Beware module globals also. > I think they're rare enough that I disagree strongly. I'd really like to fix this too, at least put fields in the "segments" to give backends a chance... Again, though, I don't want to change and recompile anything to debug. Just like normal code. If I'm going to recompile..well, then RTIO.PutText/printf/OutputDebugStringA/DbgPrint like crazy. Sadly, I do a lot of that. Other than an external file, compilers have support for "sections" -- you can put the "cold" code/data "out of the way", but in the same file.There are tradeoffs either way.External files are the way on Windows and increasingly the way on Unix.But then you have to somehow find the file."Internal" is great for ease of finding. Some systems (VMS) keep a minimal amount in the code, and I guess, the rest outside. > Recompile time is quick compared to the overhead this would introduce. The idea is to debug w/o source and compiler.But it is a slippery slope. Full "internal debugging" puts "almost" the source in the executable.Is source absent because it is secret? or large? Or always present? - Jay Subject: Re: [M3devel] Internal debugging - a simple design From: darko at darko.org Date: Tue, 2 Apr 2013 15:54:41 -0700 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On Apr 2, 2013, at 3:39 PM, Jay K wrote:I don't want to have to recompile anything. Ideally the overhead of the debug stuff is low enough that it is always on. That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size. I believe you need to make a function call for every line or "instruction". That is the hook for stepping and breakpoints. I don't think this is required. If you want to break you put in a call in your code. Recompile time is quick compared to the overhead this would introduce. You need function calls to the debugger for every assignment. If you have something like "watch breakpoints" ("Break whenv variable x becomes 123.") On the assignment matter though, it could be done in the step/instruction call. Again, if you want this you put a call in your code, just like the existing pragma. There isn't necessarily a zero offset for parameters and locals.. well..a debug system probably creates one..homing all the parameters and not enregistering everything.. You should probably bundle up the data into a smaller number of linked structures, in order to pass fewer parameters to DebugProcEntry. Notice the offset is an integer, along with a special number for registers and pesudo-functions to access them, wouldn't that avoid changes for debugging? Beware module globals also. Even in my upcoming C backend work, they don't work well. I think that needs frontend work. :( I think they're rare enough that they could be handled with functions instead of this debugging code. - Jay > From: darko at darko.org > Date: Tue, 2 Apr 2013 10:51:48 -0700 > To: m3devel at elegosoft.com > Subject: [M3devel] Internal debugging - a simple design > > Here's an idea for how simple internal debugging might work. > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > CONST > ProcName: TEXT = "Module.ProcName"; > ProcType: CARDINAL = 12345678; > ProcAdr: ADDRESS = 123456; > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > ReturnType: CARDINAL = 12345678; > ReturnOffs: INTEGER = 32; > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > PROCEDURE DebugProcEntry( > READONLY frame: ADDRESS; > READONLY procName: ProcName; > READONLY procType: ProcType; > READONLY procAdr: ProcAdr; > READONLY paramNames: ParamNames; > READONLY paramTypes: ParamTypes; > READONLY paramOffs: ParamOffs; > READONLY returnType: ReturnType; > READONLY returnOffs: ReturnOffs; > READONLY localNames: LocalNames; > READONLY localTypes: LocalTypes; > READONLY localOffs: LocalOffs > ); > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > - Darko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Apr 3 00:54:41 2013 From: darko at darko.org (Darko) Date: Tue, 2 Apr 2013 15:54:41 -0700 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> Message-ID: <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> On Apr 2, 2013, at 3:39 PM, Jay K wrote: > I don't want to have to recompile anything. > Ideally the overhead of the debug stuff is low enough that it is always on. > That is difficult. Or maybe everything is so fast these days that we can just be inefficient. Nobody noticed how bad cm3cg's codegen was, after all, or that it got better. The constant debug information has to be stored somewhere, I guess it could be an external file to avoid increasing code size. > I believe you need to make a function call for every line or "instruction". > That is the hook for stepping and breakpoints. I don't think this is required. If you want to break you put in a call in your code. Recompile time is quick compared to the overhead this would introduce. > You need function calls to the debugger for every assignment. > If you have something like "watch breakpoints" > ("Break whenv variable x becomes 123.") > On the assignment matter though, it could be done in the step/instruction call. Again, if you want this you put a call in your code, just like the existing pragma. > There isn't necessarily a zero offset for parameters and locals.. > well..a debug system probably creates one..homing all the parameters > and not enregistering everything.. > You should probably bundle up the data into a smaller number of linked structures, > in order to pass fewer parameters to DebugProcEntry. Notice the offset is an integer, along with a special number for registers and pesudo-functions to access them, wouldn't that avoid changes for debugging? > > > Beware module globals also. > Even in my upcoming C backend work, they don't work well. > I think that needs frontend work. :( > I think they're rare enough that they could be handled with functions instead of this debugging code. > > - Jay > > > > > > From: darko at darko.org > > Date: Tue, 2 Apr 2013 10:51:48 -0700 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Internal debugging - a simple design > > > > Here's an idea for how simple internal debugging might work. > > > > A command line option is created that turns on debug code generation globally. A pragma is created, <*DEBUG*> which turns on debugging for all of the procedures within the scope that the pragma precedes, being an implementation module or a possibly nested procedure. Both must be done for debugging code to actually be generated for a procedure. > > > > For each procedure within a debugging scope the following declaration is inserted (the offsets are byte offsets): > > > > CONST > > ProcName: TEXT = "Module.ProcName"; > > ProcType: CARDINAL = 12345678; > > ProcAdr: ADDRESS = 123456; > > ParamNames = ARRAY OF TEXT{"param1", "param2", "param3"}; > > ParamTypes = ARRAY OF CARDINAL{1, 2, 3}; > > ParamOffs = ARRAY OF INTEGER{0, 4, 8, 16); > > ReturnType: CARDINAL = 12345678; > > ReturnOffs: INTEGER = 32; > > LocalNames = ARRAY OF TEXT{"local1", "local2", "local3"}; > > LocalTypes = ARRAY OF CARDINAL{1, 2, 3}; > > LocalOffs = ARRAY OF INTEGER{20, 24, 28, 36); > > > > Extra calls are inserted into a procedure within a debugging scope so that whenever the procedure is called DebugProcEntry is called first. DebugProcEntry must be declared or imported in the procedure's module. DebugProcEntry passes all the above constant declarations as parameters, plus an extra parameter which gives the address of the zero offset for the parameters and local variables: > > > > PROCEDURE DebugProcEntry( > > READONLY frame: ADDRESS; > > READONLY procName: ProcName; > > READONLY procType: ProcType; > > READONLY procAdr: ProcAdr; > > READONLY paramNames: ParamNames; > > READONLY paramTypes: ParamTypes; > > READONLY paramOffs: ParamOffs; > > READONLY returnType: ReturnType; > > READONLY returnOffs: ReturnOffs; > > READONLY localNames: LocalNames; > > READONLY localTypes: LocalTypes; > > READONLY localOffs: LocalOffs > > ); > > > > Whenever a procedure returns a procedure called DebugProcExit is called just before it exits, with the same parameters as DebugProcEntry. > > > > - Darko > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 3 04:51:15 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 2 Apr 2013 22:51:15 -0400 Subject: [M3devel] Internal debugging - a simple design In-Reply-To: References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org> <3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org> Message-ID: <20130403025115.GA30084@topoi.pooq.com> On Wed, Apr 03, 2013 at 12:45:23AM +0000, Jay K wrote: > Again, though, I don't want to change and recompile anything to debug. Then an interpreter could be your friend. > The idea is to debug w/o source and compiler.But it is a slippery > slope. Full "internal debugging" puts "almost" the source in the > executable.Is source absent because it is secret? or large? Or always > present? The old Algol W compiler on the IBM 360 could be asked to place a trimmed-down copy of the source code somewhere (in memory if I recall correctly). It would contain bytecodes for reserved words and operators, indexes into a symbol table for identifiers, and the like. Then every time execution would enter a basic block, it would increment a counter -- one counter for each basic block. When execution finished, it would prepare a printout, expanding all those brief byte codes and indices, indenting properly, and printing the count beside the start of every basic block. I would debug from this listing and suppress the usual source-code listing. This count-annotated listing was much more useful. -- hendrik From jay.krell at cornell.edu Wed Apr 3 10:46:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 08:46:10 +0000 Subject: [M3devel] cost of opaque types Message-ID: cost of opaque types fyi: PutI(cstr("Public.F1.a.c"), a.c); PutI == put_adr L_22_L_23 the string L_26_L_27 == a 8 is the "public offset" of c M_Public_L_19 globals for Public.m3 everything else is the computation of the "public base" of a from the base of a actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); simplify slightly (how I wish it got printed...): put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); I still have to track down the whole "recompile again now that offsets are known" path. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Apr 3 15:03:31 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 3 Apr 2013 15:03:31 +0200 Subject: [M3devel] cost of opaque types In-Reply-To: References: Message-ID: <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> There are languages, C# and Java coming to mind? where people accept a lot more from language/compiler for various reasons. :) -- Dragi?a Duri? dragisha at m3w.org On Apr 3, 2013, at 10:46 AM, Jay K wrote: > cost of opaque types > > > fyi: > > PutI(cstr("Public.F1.a.c"), a.c); > > > PutI == put_adr > L_22_L_23 the string > L_26_L_27 == a > 8 is the "public offset" of c > M_Public_L_19 globals for Public.m3 > > > everything else is the computation of the "public base" of a from the base of a > > > actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c > > > put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); > > > simplify slightly (how I wish it got printed...): > > put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); > > > > I still have to track down the whole "recompile again now that offsets are known" path. > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Apr 3 20:53:40 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 03 Apr 2013 11:53:40 -0700 Subject: [M3devel] Why do we need external debugging? In-Reply-To: References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org> Message-ID: <20130403185340.DC3811A207D@async.async.caltech.edu> All my bigger Modula-3 programs these days include a Scheme interpreter that understands most types in the language... it's not too far from a debugger. Mika Darko writes: > >--Apple-Mail-19-23585903 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=us-ascii > >Can't say I like VS, though I have used it. I didn't really use any of = >the features except the stack dump. For a language like M3 internal = >debugging makes a lot of sense since it's unlikely to affect anything = >else, and I like the idea of being able to customize it for my own = >purposes while maintaining performance. Maybe a simple object based = >"plug in" architecture would work well. > > >On Apr 1, 2013, at 9:22 PM, Jay K wrote: > >> External debuggers are good. Have you used Visual Studio much? >> Generate the right debug information and we get excellent working = >debuggers that people put a lot of time and work into. >>=20 >>=20 >> On the other hand, I do understand your notion of "internal debugger" = >and agree it is a good approach. >>=20 >>=20 >> - Jay >>=20 >>=20 >>=20 >> > From: darko at darko.org >> > Date: Mon, 1 Apr 2013 14:53:37 -0700 >> > To: m3devel at elegosoft.com >> > Subject: [M3devel] Why do we need external debugging? >> >=20 >> > The last time I used an external or lowish-level debugger was the = >last time I programmed in a language other than M3. I find the language = >so safe and reliable that I don't quite understand the need for external = >debuggers. Is it driven by a need to integrate with other languages or = >external libraries? >> >=20 >> > Why can't a debugger be optionally compiled into the code and = >supported by the runtime? I find I don't need much more than the ability = >to log procedure execution, procedure parameters and local variables. I = >imagine some sort of debugging mode with a simple command line and an = >interrupt mechanism would facilitate interactive debugging. >> >=20 >> > Am I the only one who thinks this? >> >=20 >> > - Darko >> >=20 > > >--Apple-Mail-19-23585903 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=us-ascii > >-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Can't = >say I like VS, though I have used it. I didn't really use any of the = >features except the stack dump. For a language like M3 internal = >debugging makes a lot of sense since it's unlikely to affect anything = >else, and I like the idea of being able to customize it for my own = >purposes while maintaining performance. Maybe a simple object based = >"plug in" architecture would work = >well.


On Apr 1, 2013, at 9:22 PM, Jay K = >wrote:

type=3D"cite">separate; font-family: Helvetica; font-style: normal; font-variant: = >normal; font-weight: normal; letter-spacing: normal; line-height: = >normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = >text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
class=3D"hmmessage" style=3D"font-size: 12pt; font-family: Calibri; = >">
External debuggers are good. Have you used Visual = >Studio much?
Generate the right debug information and we get = >excellent working debuggers that people put a lot of time and work = >into.


On the other hand, I do understand your notion of = >"internal debugger" and agree it is a good approach.


 - = >Jay



> = >From: href=3D"mailto:darko at darko.org">darko at darko.org
> Date: Mon, 1 = >Apr 2013 14:53:37 -0700
> To:class=3D"Apple-converted-space"> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = >Subject: [M3devel] Why do we need external debugging?
>class=3D"Apple-converted-space"> 
> The last time I = >used an external or lowish-level debugger was the last time I programmed = >in a language other than M3. I find the language so safe and reliable = >that I don't quite understand the need for external debuggers. Is it = >driven by a need to integrate with other languages or external = >libraries?
>class=3D"Apple-converted-space"> 
> Why can't a = >debugger be optionally compiled into the code and supported by the = >runtime? I find I don't need much more than the ability to log procedure = >execution, procedure parameters and local variables. I imagine some sort = >of debugging mode with a simple command line and an interrupt mechanism = >would facilitate interactive debugging.
>class=3D"Apple-converted-space"> 
> Am I the only one = >who thinks this?
>class=3D"Apple-converted-space"> 
> - = >Darko
>class=3D"Apple-converted-space"> 
= >

= > >--Apple-Mail-19-23585903-- From dragisha at m3w.org Wed Apr 3 23:54:23 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 3 Apr 2013 23:54:23 +0200 Subject: [M3devel] UTF8, a three zeros library Message-ID: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Zero UNSAFE, zero libc, zero C. https://dl.dropbox.com/u/60554338/UTF8.zip I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8? Suggestions are welcome. And criticism is not unwelcome :). -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Thu Apr 4 00:26:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 22:26:10 +0000 Subject: [M3devel] cost of opaque types In-Reply-To: <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> References: , <3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org> Message-ID: If my opaque type exposes no public data, only functions, then I think I'll win significantly by just using "fully transparent prefix object types". I have to check if method calls incur a similar extra overhead. You know, if you have: TYPE T <: OBJECT METHODS F1(); END;NEW(T); vs. interfaceTYPE T = OBJECT METHODS F1(); END; module TYPE TImpl = T OBJECT more stuff END;PROCEDURE CreateT():T = BEGIN RETURN NEW(TImpl); END CreateT; the level of opacity is the same, but the second form likely has much lower overhead. The difference being that you can't directly NEW the type, you have to use a special creator function. Debugging might might might be better in the first case, esp. with stock debuggers, if the backend has or finds enough information (imagine -- backend doesn't really have to be unit-at-a-time..it can sit around building everything in memory..waiting for all the type revelations..and generate everything into one C or .asm or whatever file...) That is, the second case is common in C++ a la COM, and debuggers often only show a vtable and function pointers -- the base type. They ought to figure out from the vtable the leaf type and show everything..maybe Visual Studio does..I use windbg more... - Jay Subject: Re: [M3devel] cost of opaque types From: dragisha at m3w.org Date: Wed, 3 Apr 2013 15:03:31 +0200 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu There are languages, C# and Java coming to mind. where people accept a lot more from language/compiler for various reasons. :) --Dragi?a Duri?dragisha at m3w.org On Apr 3, 2013, at 10:46 AM, Jay K wrote:cost of opaque types fyi: PutI(cstr("Public.F1.a.c"), a.c); PutI == put_adr L_22_L_23 the string L_26_L_27 == a 8 is the "public offset" of c M_Public_L_19 globals for Public.m3 everything else is the computation of the "public base" of a from the base of a actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19))))))))))))))))); simplify slightly (how I wish it got printed...): put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19))); I still have to track down the whole "recompile again now that offsets are known" path. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 4 00:20:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Apr 2013 22:20:33 +0000 Subject: [M3devel] UTF8, a three zeros library In-Reply-To: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Message-ID: attached my UTF8 library.. clear, simple, Czero libc, zero Modula-3 :) - Jay From: dragisha at m3w.org Date: Wed, 3 Apr 2013 23:54:23 +0200 To: m3devel at elegosoft.com Subject: [M3devel] UTF8, a three zeros library Zero UNSAFE, zero libc, zero C. https://dl.dropbox.com/u/60554338/UTF8.zip I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8. Suggestions are welcome. And criticism is not unwelcome :). --Dragi?a Duri?dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: utf8.c URL: From dragisha at m3w.org Thu Apr 4 00:28:58 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 4 Apr 2013 00:28:58 +0200 Subject: [M3devel] UTF8, a three zeros library In-Reply-To: References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org> Message-ID: Great code? maybe a bit short on readability side? :) -- Dragi?a Duri? dragisha at m3w.org On Apr 4, 2013, at 12:20 AM, Jay K wrote: > attached my UTF8 library.. > > clear, simple, C > zero libc, zero Modula-3 :) > > > - Jay > From: dragisha at m3w.org > Date: Wed, 3 Apr 2013 23:54:23 +0200 > To: m3devel at elegosoft.com > Subject: [M3devel] UTF8, a three zeros library > > Zero UNSAFE, zero libc, zero C. > > https://dl.dropbox.com/u/60554338/UTF8.zip > > I needed this to iterate through UTF8 glyphwise, and to get substrings as TEXT. Also, to validate UTF8. > > Suggestions are welcome. And criticism is not unwelcome :). > -- > Dragi?a Duri? > dragisha at m3w.org > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Apr 6 20:40:01 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 6 Apr 2013 20:40:01 +0200 Subject: [M3devel] NARROW(refanyValue, procedureType) Message-ID: Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? new source -> compiling XLModule.m3 "../src/XLModule.m3", line 181: NARROW: types must be assignable "../src/XLModule.m3", line 239: incompatible types (x) Second one is RefSeq.T.addhi(procedureType) TIA, dd -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mika at async.caltech.edu Sat Apr 6 22:51:45 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 06 Apr 2013 13:51:45 -0700 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: References: Message-ID: <20130406205145.6F2641A207D@async.async.caltech.edu> I think it works as long as you define a (fully specified) wrapper type. e.g., TYPE P = PROCEDURE (x, y : INTEGER) : INTEGER; W = REF RECORD p : P END; ... PROCEDURE Add(x, y : INTEGER) : INTEGER = ... TextWTbl wtbl... wtbl.put("add", NEW(W, p := Add)); ... =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF >Content-Type: multipart/alternative; > boundary="Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4" > > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=utf-8 > >Is this possible in any way? Can I use any Sequence/Table type to hold = >procedure typed values inside? > >new source -> compiling XLModule.m3 >"../src/XLModule.m3", line 181: NARROW: types must be assignable >"../src/XLModule.m3", line 239: incompatible types (x) > >Second one is RefSeq.T.addhi(procedureType) > >TIA, >dd >-- >Dragi=C5=A1a Duri=C4=87 >dragisha at m3w.org > > > > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=utf-8 > >-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Is = >this possible in any way? Can I use any Sequence/Table type to hold = >procedure typed values inside?

new source -> = >compiling XLModule.m3
"../src/XLModule.m3", line 181: NARROW: = >types must be assignable
"../src/XLModule.m3", line 239: = >incompatible types (x)

Second one is = >RefSeq.T.addhi(procedureType)

TIA,
dddiv>
>
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = >Helvetica; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; orphans: 2; = >text-align: -webkit-auto; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; = >">
--
style=3D"font-family: Helvetica; ">Dragi=C5=A1a Duri=C4=87class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = >rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: = >normal; font-weight: normal; letter-spacing: normal; line-height: = >normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = >text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: = >Helvetica; font-style: normal; font-variant: normal; font-weight: = >normal; letter-spacing: normal; line-height: normal; orphans: 2; = >text-align: -webkit-auto; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >-webkit-line-break: after-white-space; ">

= >

>
>
= > >--Apple-Mail=_A84F0FAA-1961-4C86-AD4B-C98D5D8A4EC4-- > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename=signature.asc >Content-Type: application/pgp-signature; > name=signature.asc >Content-Description: Message signed with OpenPGP using GPGMail > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > >iQEcBAEBAgAGBQJRYGwFAAoJEJtljYXUJo8xGvgH/0MAKizqVsumCaf25qcldgcH >PPBGWW5VPRmTEDU2sgRD+1HdkiXwW9Bq5l6Ywv6uIdbZF5SYv64+EAwb9ZCBwIDo >2SxOKZmr0Z4ECl5Jyn6MgZxIOq4sVdHhQ+F5k/1o7C0v7x582A0Td8QnvijoQdRs >LQqQW9ZNYlLDf57dlpCm5+baXem8KO1PNo7Z4If2ceTEaqIb++Ax/Nc8wzEqN1uD >br4GfPKzNmJgQ6RlHbqdoesM4HmbdF2nxMSkVdA8Ydgi5EQH4zBEKFfOsp1uzRjC >VtUkeBwhQyLWNQaaJlR4rzbMDLJprdIyrs9WYQKMALGoYZQiDecy/oH6s8Awgi0= >=tvjq >-----END PGP SIGNATURE----- > >--Apple-Mail=_6C972875-A6B1-4175-AD68-BEF89BE30CCF-- From jay.krell at cornell.edu Sat Apr 6 23:59:26 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Apr 2013 21:59:26 +0000 Subject: [M3devel] alternate implementation of opaque types? Message-ID: Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? We do suffer from the "fragile base type" problem either way, right? Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. With my proposed change, you can recompile less actually. Though we probably wouldn't bother. As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 01:23:38 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Apr 2013 23:23:38 +0000 Subject: [M3devel] cm3 should process -D on command line earlier? Message-ID: > cm3 should process -D on command line earlier? I want to be able to say in the config file: if defined("cm3_verbose") M3_FRONT_FLAGS += ["-v"] end if defined("cm3_verbose_version_stamps") M3_FRONT_FLAGS += ["-vsdebug"] end this doesn't quite work because cm3 processes the -D on the command line fairly late -- after it reads "the config file" and before it reads "the m3makefile". (Each of which can and often does include additional files.) I'm working on this change. Alternative a specific flag to cm3 for each frontend flag might be good. I guess verbose is actually already handled. Shall I just "pretend" they are the same? Add frontend flags to cm3 and have cm3 pass them on? i.e. specifically -vsdebug? see /cm3/m3-sys/m3front/src/misc/Host.m3 for possible frontend flags Hm..the thing is, these are mostly meant to be pretty obscure. Often-but-not-always target-specific, set by the config file, and not meant to be user-editable. For example the C backend and NT386 backend have requirements around -inline_nested_procs vs. -unfold_nested_procs. Though really the C backend could easily be made to work either way, esp. at this point that it is many-pass. Reasonable? (I'm specifically wanting -vsdebug to track down what types the C backend is seemingly uninformed about...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 07:56:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 05:56:29 +0000 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? Message-ID: In the C backend, I would like to share code for records and objects. As I understand, objects are always pointers. In my framework, I map typeids to type information. For this to work, given an object, I need to declare both a record and a pointer to it. I need two typeids for that. I'm in the position where I need to compute a typeid. Is that feasible? I have two choices if I can't do that: 1) map from strings instead, where the strings tend to be a string form of a typeid, but where I can make up other forms; quite an inefficiency 1b) have two maps maybe 2) build a flag into my record data that indicates "record or object" #1 is easy but I'm leary of the inefficiency. I'll probably try #2 instead then. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 08:26:46 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 06:26:46 +0000 Subject: [M3devel] m3front/src/types/TypeRep.i3 NO_UID Message-ID: m3front/src/types/TypeRep.i3 NO_UID = -1 is it really guaranteed that a typeid won't end up being -1? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Apr 7 10:03:46 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Apr 2013 10:03:46 +0200 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: Message-ID: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> I second this. I never had problems with these instances of "over-compilation". Why bother, and why introduce possible problems down the road by fixing what is not broken? -- Dragi?a Duri? dragisha at m3w.org On Apr 6, 2013, at 11:59 PM, Jay K wrote: > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 7 13:09:51 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Apr 2013 21:09:51 +1000 Subject: [M3devel] m3front/src/types/TypeRep.i3 NO_UID In-Reply-To: References: Message-ID: Yes. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Apr 7, 2013, at 4:26 PM, Jay K wrote: > m3front/src/types/TypeRep.i3 NO_UID = -1 > is it really guaranteed that a typeid won't end up being -1? > > > Thanks, > - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 7 13:10:03 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Apr 2013 21:10:03 +1000 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> References: <9E50F987-ECAE-40B2-A930-0B90DC9F95D5@m3w.org> Message-ID: <5618C4A4-E9AB-460F-BAF6-D59B0623DDA4@cs.purdue.edu> There can be multiple levels of opacity. So I don?t see how you would do this. On Apr 7, 2013, at 6:03 PM, Dragi?a Duri? wrote: > I second this. I never had problems with these instances of "over-compilation". Why bother, and why introduce possible problems down the road by fixing what is not broken? > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Apr 6, 2013, at 11:59 PM, Jay K wrote: > >> With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 7 17:48:57 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 10:48:57 -0500 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: Message-ID: <51619569.4070202@lcwb.coop> On 04/06/2013 04:59 PM, Jay K wrote: > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > This is neither an implementation nor a language design question, but a programmer's option. The language allows private things before or after public, or more complicated combinations, e.g., private, public, private. In fact, arbitrary combinations are possible, although how to put them together gets tricky and requires a lot of separate compilations. Here is a public-private-public example that is, I think, believable: INTERFACE Stack ; TYPE T <: Public ; TYPE Public = OBJECT METHODS push ( I : INTEGER ) ... END (* Public *) ; END Stack . (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) Later, somebody else wants to add: INTERFACE StackWithStats ; IMPORT Stack ; TYPE T = Stack . T OBJECT PushCt : CARDINAL := 0 ... OVERRIDES push := Push ... END (* T *) ; PROCEDURE Push ( s : T ; I : INTEGER ) ; END StackWithStats . MODULE StackWithStats ; PROCEDURE Push ( s : T ; I : INTEGER ) = BEGIN INC ( s . PushCt ) ; Stack . T . push ( s , I ) END Push ... ; BEGIN END StackWithStats . > > We do suffer from the "fragile base type" problem either way, right? > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > - Jay From rodney_bates at lcwb.coop Sun Apr 7 18:02:51 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 11:02:51 -0500 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: References: Message-ID: <516198AB.5040509@lcwb.coop> On 04/07/2013 12:56 AM, Jay K wrote: > In the C backend, I would like to share code for records and objects. > > > As I understand, objects are always pointers. Yes. > > > In my framework, I map typeids to type information. > > > For this to work, given an object, I need to declare both a record > and a pointer to it. I need two typeids for that. > > > I'm in the position where I need to compute a typeid. > Is that feasible? > > > > I have two choices if I can't do that: > > > 1) map from strings instead, where the strings tend to be > a string form of a typeid, but where I can make up other forms; > quite an inefficiency > > > 1b) have two maps maybe > > > > 2) build a flag into my record data that indicates "record or object" FWIW, I believe it is true that every way of using an object type in Modula-3 implicitly and uniquely identifies whether it works on the pointer or the heap object. For example, := and = mean the pointer, while any use of . implies dereferencing. There is no whole-object assignment or whole-object comparison, as there are for REF RECORD (which has two types). Maybe this distinction is lost in the lowering that happens by the time M3C gets it, or later. > > > #1 is easy but I'm leary of the inefficiency. > I'll probably try #2 instead then. > > > > - Jay > > From rodney_bates at lcwb.coop Sun Apr 7 18:21:40 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 07 Apr 2013 11:21:40 -0500 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: References: Message-ID: <51619D14.6070903@lcwb.coop> On 04/06/2013 01:40 PM, Dragi?a Duri? wrote: > Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? > > new source -> compiling XLModule.m3 > "../src/XLModule.m3", line 181: NARROW: types must be assignable > "../src/XLModule.m3", line 239: incompatible types (x) > From 2.2.10: NULL <: REF T <: REFANY and similarly, any object type <: ROOT <: REFANY but while NULL <: PROCEDURE... NOT PROCEDURE... <: REFANY nor PROCEDURE... <: ADDRESS Which is why you can't assign a procedure value to a pointer of any kind, nor can you narrow a pointer back to a procedure. Changing the language to allow this would, I think, entail significant implementation complexity. Do you want all of the procedure values in the sequence to be the same procedure type? If so, you should be able to just instantiate Sequence using an interface containing a T that is this procedure type. No runtime NARROW overhead, and more static checking. Otherwise, Mika's wrapping example should be extensible by having a different wrapper type around each needed procedure type. Then they could be mixed and matched in a single sequence. > Second one is RefSeq.T.addhi(procedureType) > > TIA, > dd > -- > Dragi?a Duri? > dragisha at m3w.org > > > From dragisha at m3w.org Sun Apr 7 18:47:15 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 7 Apr 2013 18:47:15 +0200 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: <51619D14.6070903@lcwb.coop> References: <51619D14.6070903@lcwb.coop> Message-ID: <4A99AADA-503C-4BA9-9FAA-9133796EA851@m3w.org> Mika's idea is exactly what I needed. I was cleaning some old code and ARRAY's of fixed size "emulating" collections are one my favourite targets :). More than enough, and more than powerful enough, this mechanism is. -- Dragi?a Duri? dragisha at m3w.org On Apr 7, 2013, at 6:21 PM, Rodney M. Bates wrote: > Do you want all of the procedure values in the sequence to be the same > procedure type? If so, you should be able to just instantiate Sequence > using an interface containing a T that is this procedure type. No > runtime NARROW overhead, and more static checking. > > Otherwise, Mika's wrapping example should be extensible by having a different > wrapper type around each needed procedure type. Then they could be mixed and > matched in a single sequence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Apr 7 19:23:59 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 07 Apr 2013 10:23:59 -0700 Subject: [M3devel] NARROW(refanyValue, procedureType) In-Reply-To: <51619D14.6070903@lcwb.coop> References: <51619D14.6070903@lcwb.coop> Message-ID: <20130407172359.7DD2E1A207D@async.async.caltech.edu> I should add that m3tk could be used to generate such procedure type wrappers automatically. It's one of the things I never got around to in my Scheme system (since you can usually just use OBJECTs anyhow, at least if you control the source code), but it shouldn't be too difficult... Mika "Rodney M. Bates" writes: > > >On 04/06/2013 01:40 PM, Dragi??a Duri?? wrote: >> Is this possible in any way? Can I use any Sequence/Table type to hold procedure typed values inside? >> >> new source -> compiling XLModule.m3 >> "../src/XLModule.m3", line 181: NARROW: types must be assignable >> "../src/XLModule.m3", line 239: incompatible types (x) >> > > From 2.2.10: > >NULL <: REF T <: REFANY >and similarly, any object type <: ROOT <: REFANY > >but while NULL <: PROCEDURE... >NOT PROCEDURE... <: REFANY nor PROCEDURE... <: ADDRESS > >Which is why you can't assign a procedure value to a pointer of any kind, nor >can you narrow a pointer back to a procedure. Changing the language to allow >this would, I think, entail significant implementation complexity. > >Do you want all of the procedure values in the sequence to be the same >procedure type? If so, you should be able to just instantiate Sequence >using an interface containing a T that is this procedure type. No >runtime NARROW overhead, and more static checking. > >Otherwise, Mika's wrapping example should be extensible by having a different >wrapper type around each needed procedure type. Then they could be mixed and >matched in a single sequence. > >> Second one is RefSeq.T.addhi(procedureType) >> >> TIA, >> dd >> -- >> Dragi??a Duri?? >> dragisha at m3w.org >> >> >> From hendrik at topoi.pooq.com Sun Apr 7 20:37:46 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 7 Apr 2013 14:37:46 -0400 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: <516198AB.5040509@lcwb.coop> References: <516198AB.5040509@lcwb.coop> Message-ID: <20130407183746.GB24973@topoi.pooq.com> On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote: > > > On 04/07/2013 12:56 AM, Jay K wrote: > >In the C backend, I would like to share code for records and objects. > > > > > >As I understand, objects are always pointers. > > Yes. > > > > > > >In my framework, I map typeids to type information. > > > > > >For this to work, given an object, I need to declare both a record > >and a pointer to it. I need two typeids for that. > > > > > >I'm in the position where I need to compute a typeid. > >Is that feasible? > > > > > > > >I have two choices if I can't do that: > > > > > > 1) map from strings instead, where the strings tend to be > > a string form of a typeid, but where I can make up other forms; > > quite an inefficiency > > > > > > 1b) have two maps maybe > > > > > > > > 2) build a flag into my record data that indicates "record or object" > > FWIW, I believe it is true that every way of using an object type in Modula-3 > implicitly and uniquely identifies whether it works on the pointer or the > heap object. For example, := and = mean the pointer, while any use of . implies > dereferencing. There is no whole-object assignment or whole-object comparison, > as there are for REF RECORD (which has two types). > > Maybe this distinction is lost in the lowering that happens by the time M3C gets it, > or later. I this matter Modula 3 is very different from C++, which idenntifies classes wiith structure types. It even treats struct and class as equivalent keywords. That was a big mistake in C++, and results in pathological behavior when assigning class values instead of class pointers. -- hendrik k From jay.krell at cornell.edu Sun Apr 7 21:07:15 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 19:07:15 +0000 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: <51619569.4070202@lcwb.coop> References: , <51619569.4070202@lcwb.coop> Message-ID: My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > The language allows private things before or after public, or more complicated combinations, I didn't realize. - Jay > Date: Sun, 7 Apr 2013 10:48:57 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > This is neither an implementation nor a language design question, but a programmer's option. > The language allows private things before or after public, or more complicated combinations, > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > to put them together gets tricky and requires a lot of separate compilations. > > Here is a public-private-public example that is, I think, believable: > > INTERFACE Stack > ; TYPE T <: Public > ; TYPE Public = OBJECT METHODS > push ( I : INTEGER ) > ... > END (* Public *) > ; END Stack . > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > Later, somebody else wants to add: > > INTERFACE StackWithStats > ; IMPORT Stack > ; TYPE T = Stack . T OBJECT > PushCt : CARDINAL := 0 > ... > OVERRIDES > push := Push > ... > END (* T *) > ; PROCEDURE Push ( s : T ; I : INTEGER ) > ; END StackWithStats . > > MODULE StackWithStats > ; PROCEDURE Push ( s : T ; I : INTEGER ) > = BEGIN > INC ( s . PushCt ) > ; Stack . T . push ( s , I ) > END Push > ... > ; BEGIN END StackWithStats . > > > > > We do suffer from the "fragile base type" problem either way, right? > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 7 21:16:41 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Apr 2013 19:16:41 +0000 Subject: [M3devel] computing a typeid in backend for a pointer to a declared type?? In-Reply-To: <20130407183746.GB24973@topoi.pooq.com> References: , <516198AB.5040509@lcwb.coop>, <20130407183746.GB24973@topoi.pooq.com> Message-ID: I figured out a way that probably works. I use -1 for the typeid of the made up record, and hope that I don't need it. What C++ does makes a lot of sense actually. What you are missing is that "classes" or "types" have different use-cases. More than 2. Stroustrup identifies a few. Off the top of my head, though: 1) value types like std::string Here the value semantics are what you want. This also includes container classes like std::vector, std::queue, etc., that you don't often want to assign, but when you do, they offer a good way to do it. 2) typical "object oriented stuff" like "Window" with virtual functions that get overridden 3) "object oriented stuff" w/ plugins like how Modula-3 Rd/Wr work and how C++ iostreams work -- you plugin a "buffer". You always call "toplevel" non-overridden functions that selectively call more derived overrides. The toplevel provides a "framework" and common code is lifted out of the derived types, leaving them only to implement "what varies". I think actually in general #2 is overrused and #3 is kind of better. #1 is different and appropriately often used. 4) Sometimes just for scoping globals, i.e. "singleton" / "manager" classes. The way you enforce stuff is that types that aren't meant to be assigned should have abstract functions, so you can't instantiate them directly. And then, also, you wrap up #2/#3 in #1 -- std::unique_ptr / std::shared_ptr and such. Modula-3 favors only #2 or #3. Many languages don't have good support for #1 really. You know -- Modula-3 TEXT and java String get special treatment by the compiler and w/o compiler support, nobody can implement anything quite like them, whereas C++ std::string is implemented with powers available to anyone. Anyway, I think I solved my problem. Aside from opaque types always being "ADDRESS", I have good typeinfo in the C backend now. Also exluding global variables, which remain awful. Now to start using these types for locals/parameters... - Jay > Date: Sun, 7 Apr 2013 14:37:46 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] computing a typeid in backend for a pointer to a declared type?? > > On Sun, Apr 07, 2013 at 11:02:51AM -0500, Rodney M. Bates wrote: > > > > > > On 04/07/2013 12:56 AM, Jay K wrote: > > >In the C backend, I would like to share code for records and objects. > > > > > > > > >As I understand, objects are always pointers. > > > > Yes. > > > > > > > > > > >In my framework, I map typeids to type information. > > > > > > > > >For this to work, given an object, I need to declare both a record > > >and a pointer to it. I need two typeids for that. > > > > > > > > >I'm in the position where I need to compute a typeid. > > >Is that feasible? > > > > > > > > > > > >I have two choices if I can't do that: > > > > > > > > > 1) map from strings instead, where the strings tend to be > > > a string form of a typeid, but where I can make up other forms; > > > quite an inefficiency > > > > > > > > > 1b) have two maps maybe > > > > > > > > > > > > 2) build a flag into my record data that indicates "record or object" > > > > FWIW, I believe it is true that every way of using an object type in Modula-3 > > implicitly and uniquely identifies whether it works on the pointer or the > > heap object. For example, := and = mean the pointer, while any use of . implies > > dereferencing. There is no whole-object assignment or whole-object comparison, > > as there are for REF RECORD (which has two types). > > > > Maybe this distinction is lost in the lowering that happens by the time M3C gets it, > > or later. > > I this matter Modula 3 is very different from C++, which idenntifies > classes wiith structure types. It even treats struct and class as > equivalent keywords. That was a big mistake in C++, and > results in pathological behavior when assigning class > values instead of class pointers. > > -- hendrik > k -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Mon Apr 8 12:37:46 2013 From: dmuysers at hotmail.com (Dirk Muysers) Date: Mon, 8 Apr 2013 12:37:46 +0200 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: , <51619569.4070202@lcwb.coop> Message-ID: If M3 would merge interfaces and modules, like Oberon and golang have done, with the addition of selective export (hidden, readonly, public) of record/object fields and mixins (aka called "interfaces" in Java and C#), it wouldn't need the extra complications of opaque types at all. From: Jay K Sent: Sunday, April 07, 2013 9:07 PM To: Rodney M. Bates ; m3devel Subject: Re: [M3devel] alternate implementation of opaque types? My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > The language allows private things before or after public, or more complicated combinations, I didn't realize. - Jay > Date: Sun, 7 Apr 2013 10:48:57 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > This is neither an implementation nor a language design question, but a programmer's option. > The language allows private things before or after public, or more complicated combinations, > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > to put them together gets tricky and requires a lot of separate compilations. > > Here is a public-private-public example that is, I think, believable: > > INTERFACE Stack > ; TYPE T <: Public > ; TYPE Public = OBJECT METHODS > push ( I : INTEGER ) > ... > END (* Public *) > ; END Stack . > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > Later, somebody else wants to add: > > INTERFACE StackWithStats > ; IMPORT Stack > ; TYPE T = Stack . T OBJECT > PushCt : CARDINAL := 0 > ... > OVERRIDES > push := Push > ... > END (* T *) > ; PROCEDURE Push ( s : T ; I : INTEGER ) > ; END StackWithStats . > > MODULE StackWithStats > ; PROCEDURE Push ( s : T ; I : INTEGER ) > = BEGIN > INC ( s . PushCt ) > ; Stack . T . push ( s , I ) > END Push > ... > ; BEGIN END StackWithStats . > > > > > We do suffer from the "fragile base type" problem either way, right? > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 8 18:08:08 2013 From: jay.krell at cornell.edu (Jay) Date: Mon, 8 Apr 2013 09:08:08 -0700 Subject: [M3devel] alternate implementation of opaque types? In-Reply-To: References: <51619569.4070202@lcwb.coop> Message-ID: I agree COM/Java/C# interfaces are very good for structuring large systems, maintaining opacity, and are reasonably simple and efficient. They preclude direct access to public data, for better and worse. They are achievable in Modula-3, like in C, tediously and you invent your own idiom (a separate object, with back pointer to the "real" one, and small functions to forward to it.) I don't know what Oberon/golang do here. - Jay On Apr 8, 2013, at 3:37 AM, Dirk Muysers wrote: > If M3 would merge interfaces and modules, like Oberon and golang > have done, with the addition of selective export (hidden, readonly, public) > of record/object fields and mixins (aka called "interfaces" in Java and C#), > it wouldn't need the extra complications of opaque types at all. > > From: Jay K > Sent: Sunday, April 07, 2013 9:07 PM > To: Rodney M. Bates ; m3devel > Subject: Re: [M3devel] alternate implementation of opaque types? > > My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo. > > > If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some. > > > > The language allows private things before or after public, or more complicated combinations, > > > I didn't realize. > > > - Jay > > > > Date: Sun, 7 Apr 2013 10:48:57 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] alternate implementation of opaque types? > > > > > > > > On 04/06/2013 04:59 PM, Jay K wrote: > > > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning? > > > > > > > This is neither an implementation nor a language design question, but a programmer's option. > > The language allows private things before or after public, or more complicated combinations, > > e.g., private, public, private. In fact, arbitrary combinations are possible, although how > > to put them together gets tricky and requires a lot of separate compilations. > > > > Here is a public-private-public example that is, I think, believable: > > > > INTERFACE Stack > > ; TYPE T <: Public > > ; TYPE Public = OBJECT METHODS > > push ( I : INTEGER ) > > ... > > END (* Public *) > > ; END Stack . > > > > (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. ) > > > > Later, somebody else wants to add: > > > > INTERFACE StackWithStats > > ; IMPORT Stack > > ; TYPE T = Stack . T OBJECT > > PushCt : CARDINAL := 0 > > ... > > OVERRIDES > > push := Push > > ... > > END (* T *) > > ; PROCEDURE Push ( s : T ; I : INTEGER ) > > ; END StackWithStats . > > > > MODULE StackWithStats > > ; PROCEDURE Push ( s : T ; I : INTEGER ) > > = BEGIN > > INC ( s . PushCt ) > > ; Stack . T . push ( s , I ) > > END Push > > ... > > ; BEGIN END StackWithStats . > > > > > > > > We do suffer from the "fragile base type" problem either way, right? > > > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right? > > > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type. > > > > > > > > > With my proposed change, you can recompile less actually. Though we probably wouldn't bother. > > > > > > > > > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made. > > > > > > > > > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 8 21:06:24 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Apr 2013 19:06:24 +0000 Subject: [M3devel] dbxout.c commit In-Reply-To: <20130408183918.555525DEA9D@birch.elegosoft.com> References: <20130408183918.555525DEA9D@birch.elegosoft.com> Message-ID: Note that this file is pretty dead. see cm3/m3-sys/m3cc/gcc-4.5/gcc/dbxout.c cm3/m3-sys/m3cc/gcc-4.6/gcc/dbxout.c cm3/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c cm3/m3-sys/m3cc/src/m3makefile As I recall: 4.5 was in use a while, maybe in the previous release? 4.6 I don't think was in use much, and contains the heavier handed optimizer removal by me most systems are using 4.7, but it hasn't been for long The "unversioned" directory is 4.3. We never imported 4.4. - Jay > Date: Mon, 8 Apr 2013 20:39:18 +0000 > To: m3commit at elegosoft.com > From: rodney at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rodney at birch. 13/04/08 20:39:18 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c > > Log message: > Some end-of-function comments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 9 17:52:04 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 09 Apr 2013 10:52:04 -0500 Subject: [M3devel] dbxout.c commit In-Reply-To: References: <20130408183918.555525DEA9D@birch.elegosoft.com> Message-ID: <51643924.603@lcwb.coop> Yeah, I've realized for a while I have more work than adding trivial comments, for these three new gcc backends. On 04/08/2013 02:06 PM, Jay K wrote: > Note that this file is pretty dead. > > see > cm3/m3-sys/m3cc/gcc-4.5/gcc/dbxout.c > cm3/m3-sys/m3cc/gcc-4.6/gcc/dbxout.c > cm3/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c > cm3/m3-sys/m3cc/src/m3makefile > > As I recall: > 4.5 was in use a while, maybe in the previous release? > 4.6 I don't think was in use much, and contains the heavier handed optimizer removal by me > most systems are using 4.7, but it hasn't been for long > The "unversioned" directory is 4.3. > We never imported 4.4. > > > - Jay > > > Date: Mon, 8 Apr 2013 20:39:18 +0000 > > To: m3commit at elegosoft.com > > From: rodney at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: rodney at birch. 13/04/08 20:39:18 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/: dbxout.c > > > > Log message: > > Some end-of-function comments. > > From jay.krell at cornell.edu Wed Apr 10 04:12:52 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Apr 2013 02:12:52 +0000 Subject: [M3devel] typenames vs. typeids in M3CG? Message-ID: Given something like: TYPE A = RECORD ... END; (* typeid 123456 *) TYPE B = A; VAR a:A; VAR b:B; ideally the generated code looks like: struct T123456; typedef struct T123456 T123456; struct T123456 { ... }; typedef T123456 A; typedef T123456 B; A a; B b; Currently I produce: T123456 a; T123456 b; it is easy to make the first or better yet last typename for any given typeid win, giving us: B a; B b; However actually producing the ideal/idiomatic: A a; B b; I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. Reasonable? The problem seems worst for records. But it applies to enums, subranges, opaque types. Actual source is full of typenames. M3CG is full of typeids. TYPE Color = {Red, Blue, Green}; The thing to the right is anonymous type with a typeid (structural hash). TYPE Color2 = {Red, Blue, Green}; VAR Color:c; VAR Color2:c2; In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ Color c; Color2 c2; However, again, without frontend help we are faced with probably: T1234 c; T1234 c2; or perhaps Color c; Color2 c2; Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. Similarly for opaque types, currently I have: typdef char* ADDRESS; TYPE A <: whatever; TYPE B <: whatever; typedef ADDRESS T1234; (* typeid for opaque type *) typedef ADDRESS T123478; (* typeid for opaque type *) T1234 a; T123478 b; This is not particularly readable. It can go either way: ADDRESS a; ADDRESS b; Or ideally more like: A* a; B* b; or A a; B b; Opaque types are a larger problem, at least in my head. I'd like to have pointers to structs, but I don't yet know how to make that work. Either the public part or the entire thing. If the information is available. The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) If you have used stock gdb or debugged the NT386 target, you should realize the problem. I believe the frontend should be passing typenames along with typeids for locals/parameters. I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. Advise? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Apr 10 05:43:26 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Apr 2013 13:43:26 +1000 Subject: [M3devel] typenames vs. typeids in M3CG? In-Reply-To: References: Message-ID: <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> I actually prefer the declarations T123456 a; T123456 b; Type names mean nothing in Modula-3?s structural type system. On Apr 10, 2013, at 12:12 PM, Jay K wrote: > Given something like: > > > TYPE A = RECORD ... END; (* typeid 123456 *) > TYPE B = A; > > > VAR a:A; > VAR b:B; > > > > ideally the generated code looks like: > > > struct T123456; typedef struct T123456 T123456; > struct T123456 { ... }; > > > typedef T123456 A; > typedef T123456 B; > A a; > B b; > > Currently I produce: > T123456 a; > T123456 b; > > it is easy to make the first or better yet last typename for any given typeid win, giving us: > B a; > B b; > > However actually producing the ideal/idiomatic: > A a; > B b; > > I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. > Reasonable? > > > The problem seems worst for records. > But it applies to enums, subranges, opaque types. > > > Actual source is full of typenames. M3CG is full of typeids. > > > TYPE Color = {Red, Blue, Green}; > > > The thing to the right is anonymous type with a typeid (structural hash). > > > TYPE Color2 = {Red, Blue, Green}; > > VAR Color:c; > VAR Color2:c2; > > > In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: > > typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ > > > Color c; > Color2 c2; > > > However, again, without frontend help we are faced with probably: > T1234 c; > T1234 c2; > > or perhaps > Color c; > Color2 c2; > > > Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. > That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. > > > Similarly for opaque types, currently I have: > > > typdef char* ADDRESS; > TYPE A <: whatever; > TYPE B <: whatever; > > > typedef ADDRESS T1234; (* typeid for opaque type *) > typedef ADDRESS T123478; (* typeid for opaque type *) > > > T1234 a; > T123478 b; > > > This is not particularly readable. > It can go either way: > ADDRESS a; > ADDRESS b; > > > Or ideally more like: > A* a; > B* b; > > > or > A a; > B b; > > > Opaque types are a larger problem, at least in my head. > I'd like to have pointers to structs, but I don't yet know how to make that work. > Either the public part or the entire thing. If the information is available. > > > The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. > (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) > > > If you have used stock gdb or debugged the NT386 target, you should realize the problem. > > > I believe the frontend should be passing typenames along with typeids for locals/parameters. > I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. > Advise? > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 10 17:14:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Apr 2013 15:14:27 +0000 Subject: [M3devel] typenames vs. typeids in M3CG? In-Reply-To: <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> References: , <42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu> Message-ID: In the debugger and, I somewhat lied, for the C to somewhat mimic the Modula-3, I'd definitely prefer "A" and "B". C++ programmers wrestle with this, but it is widely agreed to be a "quality bug" (correct but not ideal) and ought to be fixed. If I say: std::string a; and hover over it in a debugger, I see something ridiculous std::basic_string<...something really long>. The (Microsoft, at least) compiler was fixed to issue warnings in terms of "used types" instead of "alias bases", but the debuginfo was not. Enums are likely to end up like: enum T1234 { T1234_Red, T1234_Blue, T1234_Green }; anything given just one typename I have a chance of "fixing" well. But in the face of multiple typenames, an arbitrary one will win. I can go back and replace the text T1234 with "Color" or or "Color_" whatnot..even in the enum members. - Jay From: hosking at cs.purdue.edu Date: Wed, 10 Apr 2013 13:43:26 +1000 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] typenames vs. typeids in M3CG? I actually prefer the declarations T123456 a;T123456 b; Type names mean nothing in Modula-3?s structural type system. On Apr 10, 2013, at 12:12 PM, Jay K wrote:Given something like: TYPE A = RECORD ... END; (* typeid 123456 *) TYPE B = A; VAR a:A; VAR b:B; ideally the generated code looks like: struct T123456; typedef struct T123456 T123456; struct T123456 { ... }; typedef T123456 A; typedef T123456 B; A a; B b; Currently I produce: T123456 a; T123456 b; it is easy to make the first or better yet last typename for any given typeid win, giving us: B a; B b; However actually producing the ideal/idiomatic: A a; B b; I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. Reasonable? The problem seems worst for records. But it applies to enums, subranges, opaque types. Actual source is full of typenames. M3CG is full of typeids. TYPE Color = {Red, Blue, Green}; The thing to the right is anonymous type with a typeid (structural hash). TYPE Color2 = {Red, Blue, Green}; VAR Color:c; VAR Color2:c2; In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ Color c; Color2 c2; However, again, without frontend help we are faced with probably: T1234 c; T1234 c2; or perhaps Color c; Color2 c2; Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. Similarly for opaque types, currently I have: typdef char* ADDRESS; TYPE A <: whatever; TYPE B <: whatever; typedef ADDRESS T1234; (* typeid for opaque type *) typedef ADDRESS T123478; (* typeid for opaque type *) T1234 a; T123478 b; This is not particularly readable. It can go either way: ADDRESS a; ADDRESS b; Or ideally more like: A* a; B* b; or A a; B b; Opaque types are a larger problem, at least in my head. I'd like to have pointers to structs, but I don't yet know how to make that work. Either the public part or the entire thing. If the information is available. The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) If you have used stock gdb or debugged the NT386 target, you should realize the problem. I believe the frontend should be passing typenames along with typeids for locals/parameters. I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. Advise? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 07:14:10 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 05:14:10 +0000 Subject: [M3devel] 32bit negative base 16 constants? Message-ID: I have some 32bit constants. e.g.: CONST UID_WORD = 16_97E237E2; but this isn't right. On a 64bit system, that is a 64bit integer with a "large" positive value, instead of the intended 32bit negative value. Is there an ideal (i.e. CONST) way to do this? Portably to 64bit systems? I have found two unsatisfactory choices: 1) use decimal: #include int main() { printf("%X %d\n", 0x97E237E2); return 0; } cc 1.c ./a.out 97E237E2 -1881139893 CONST UID_WORD = (* 16_97E237E2 *) -1881139893; 2) change it to VAR and a runtime conversion: PROCEDURE SignExtend(a, b: INTEGER): INTEGER = BEGIN b := Word.LeftShift(-1, b - 1); IF Word.And(a, b) # 0 THEN a := Word.Or(a, b); END; RETURN a; END SignExtend; PROCEDURE SignExtend32(a: INTEGER): INT32 = BEGIN RETURN SignExtend(a, 32); END SignExtend32; CONST IntegerToTypeid = SignExtend32; VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) This gives a warning: CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) and then at runtime gives an error assigning it to an INT32. any other ways? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 11 08:03:02 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Apr 2013 16:03:02 +1000 Subject: [M3devel] 32bit negative base 16 constants? In-Reply-To: References: Message-ID: <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> Actually, writing that you get what you expressed: If an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation uses the convention of the Word interface. Word.T is unsigned, so you only get the 32 bits you asked for. If you want a signed value then you need to express the sign explicitly starting from a constant, just as you have done with: > CONST UID_WORD = (* 16_97E237E2 *) -1881139893; On Apr 11, 2013, at 3:14 PM, Jay K wrote: > > I have some 32bit constants. > > e.g.: > > CONST UID_WORD = 16_97E237E2; > > but this isn't right. > On a 64bit system, that is a 64bit integer > with a "large" positive value, instead of > the intended 32bit negative value. > > Is there an ideal (i.e. CONST) way to do this? > Portably to 64bit systems? > > I have found two unsatisfactory choices: > > 1) use decimal: > > #include > int main() > { > printf("%X %d\n", 0x97E237E2); > return 0; > } > > > cc 1.c > ./a.out > 97E237E2 -1881139893 > > CONST UID_WORD = (* 16_97E237E2 *) -1881139893; > > > 2) change it to VAR and a runtime conversion: > > > PROCEDURE SignExtend(a, b: INTEGER): INTEGER = > BEGIN > b := Word.LeftShift(-1, b - 1); > IF Word.And(a, b) # 0 THEN > a := Word.Or(a, b); > END; > RETURN a; > END SignExtend; > > PROCEDURE SignExtend32(a: INTEGER): INT32 = > BEGIN > RETURN SignExtend(a, 32); > END SignExtend32; > > CONST IntegerToTypeid = SignExtend32; > > > VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) > > This gives a warning: > > CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) > > and then at runtime gives an error assigning it to an INT32. > > > any other ways? > > > Thanks, > - Jay > > Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 08:17:51 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 06:17:51 +0000 Subject: [M3devel] 32bit negative base 16 constants? In-Reply-To: <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> References: , <06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu> Message-ID: I want a 32bit signed value expressed in base 16 where e.g. 16_FFFFFFFF is equivalent to -1. - Jay From: hosking at cs.purdue.edu Date: Thu, 11 Apr 2013 16:03:02 +1000 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] 32bit negative base 16 constants? Actually, writing that you get what you expressed: If an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation uses the convention of the Word interface. Word.T is unsigned, so you only get the 32 bits you asked for. If you want a signed value then you need to express the sign explicitly starting from a constant, just as you have done with: CONST UID_WORD = (* 16_97E237E2 *) -1881139893; On Apr 11, 2013, at 3:14 PM, Jay K wrote: I have some 32bit constants. e.g.: CONST UID_WORD = 16_97E237E2; but this isn't right. On a 64bit system, that is a 64bit integer with a "large" positive value, instead of the intended 32bit negative value. Is there an ideal (i.e. CONST) way to do this? Portably to 64bit systems? I have found two unsatisfactory choices: 1) use decimal: #include int main() { printf("%X %d\n", 0x97E237E2); return 0; } cc 1.c ./a.out 97E237E2 -1881139893 CONST UID_WORD = (* 16_97E237E2 *) -1881139893; 2) change it to VAR and a runtime conversion: PROCEDURE SignExtend(a, b: INTEGER): INTEGER = BEGIN b := Word.LeftShift(-1, b - 1); IF Word.And(a, b) # 0 THEN a := Word.Or(a, b); END; RETURN a; END SignExtend; PROCEDURE SignExtend32(a: INTEGER): INT32 = BEGIN RETURN SignExtend(a, 32); END SignExtend32; CONST IntegerToTypeid = SignExtend32; VAR UID_WORD := IntegerToTypeid(16_97E237E2); (* CARDINAL *) This gives a warning: CONST UID_INTEGER : INT32 = 16_195C2A74; (* INTEGER *) and then at runtime gives an error assigning it to an INT32. any other ways? Thanks, - Jay Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 10:28:22 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 08:28:22 +0000 Subject: [M3devel] temporary records lack typeids Message-ID: It'd be nice if temporary records had typeids. Specifically, it'd be nice if closures, instead of being "3 word CGType.Struct" where more like declare_record 3 fields typeidxxx declare_field integer marker declare_field address function_pointer declare_field address static_link declare_typename closure = typeidxxx Then: 1) they'd be viewable somewhat in a debugger note that the static_link is up to the backend to define. It is also a pointer to a struct, but the frontend doesn't know that 2) I could soon dispense with my mechanism for declaring structs with size but not particular fields. i.e. #define M3STRUCT(n) m3struct_##n##_t #define M3STRUCT1(n) typedef struct { volatile UINT8 a[n]; } M3STRUCT(n); #define M3STRUCT2(n) typedef struct { volatile UINT16 a[(n)/2]; } M3STRUCT(n); #define M3STRUCT4(n) typedef struct { volatile UINT32 a[(n)/4]; } M3STRUCT(n); #define M3STRUCT8(n) typedef struct { volatile UINT64 a[(n)/8]; } M3STRUCT(n); ... M3STRUCT8(8) M3STRUCT8(24) ... M3STRUCT(24) L_32_L_33 = { 0 }; all structs were using this, but now likely only closures are..er...what is that 8 byte struct? That is also something I'll remove soon, unfinished work making uplevel structs strongly typed. Maybe a long standing bug in the C backend also. I'll know soon.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 11 20:57:53 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 18:57:53 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend Message-ID: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 11 23:12:42 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Apr 2013 07:12:42 +1000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: References: Message-ID: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: > The C/C++ works, for a while now, and is improving nicely (wrt debuggability). > > > Here are some current problems/dilemnas. > > > --- getting pointer parameters correctly typed esp. on passing side --- > > > Up until now, any pointer parameter to a function has been typed as char*. > > > (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do > math on them; however given that char* is usually wrong, void* actually debugs better, > showing nothing instead of garbage. gcc does allow math on void* but it > is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; > I should probably use void* with gcc and wherever the extension is supported...autoconf...) > Anyway.. > Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). > This works but is bad for debugging (again: void* is better than char*, but both are bad) > I've been working on this. > > > The interface to the backend is > pop_param(cgtype) > pop_struct(typeid, size) > > > non-struct readonly and var parameters are just: > pop_param(cgtype.addr) > > > It would be nice if the frontend also passed a typeid here, > and either using the typeid from a "declare_indirect" or "declare_pointer" > or had separate booleans/flags for readonly/var. > > > How about: > TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); > > > might as well merge this with pop_struct, no further change required probably. > > Or, at worst, another mode: > TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); > > > or less abstract: > TYPE ParameterMode = {Value, Pointer, StructByValue}; > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); > > > or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, > I like it: > > (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant > Backends without type checking can ignore typeid. e.g. NTx86.m3. > bitSize is definitely redundant, but helps typeid-ignoring backends > that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. > cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) > cgtype will be CGType.Struct for struct-by-value (size in bitSize) > typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) > typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) > PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); > > > Ideally all backends would track typeids and it'd suffice to say: > (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) > typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) > PROCEDURE pop_param(typeid: TypeUID); > > > but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. > (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), > and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) > > > I haven't looked to see if this information (typeid/size for pop_param) > is readily available in the frontend. I will do that soon. > > > I have a few potential workarounds: > cast to void* > This appears to be working, with limited testing (my new test case, p254) > Big drawback here is the code is no longer valid C++, only C. > This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. > The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ > doesn't allow conversion from void* to other pointer types without a cast. > > > Introspect on the function pointer type and cast appropriately, or even not at all. > This should provide the ideal output and is probably viable. I'll look into it later. > > > Cast the function to (*)(...) for C++ or (*)() for C. > This is kind of gross. Hopefully it is not a deoptimization, but it might be. > I already do such casting for indirect function calls, for reasons to do with the static link. > I'm going to try this next. > > > --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- > > Now a minor dilemna, not a problem. > > > Up until recently, I didn't have much type information flowing through the C backend. > Or specifically I was only using CGType and not TypeUID. > I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. > (just some loose ends maybe around opaque types and object runtime type information. > > > I had known record sizes, but not fields. Maybe this was a dilemna already before. > > > Anyway, the point is, up until now, record passing and returning by value I have handled > internally by passing around pointers and making copies as needed (at function start). > > > I forget exactly how returning works, I'll deal with that later. > > > Passing works as follows: > caller passes pointer to record > callee has a local variable of that type > callee early on copies pointer to local variable, and references that thereafter > > > This works and has almost no downside. > It is likely how the C compiler implements things anyway. > Except maybe for "small" records/structs. Some calling conventions > do allow for passing structs/records by value in registers. > > > Passing structs/records by value is relatively rare, so we probably don't care much. > > > Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of > passing structs by value? > > > There are multiple choices: > - no, leave it alone > - yes, change it unconditionally > - leave it as a const or var in M3C.m3 > - make it #ifdefed in the output .c > > > I think for returning, we have similar choices, but the frontend is willing > to do the transform and currently does -- a matter of a boolean in Target.i3. > > > This second question has equal quality debugging either way and needs no M3CG/frontend changes > either way. (though, you know, frontend is willing to make more transforms for > record return than record pass, I believe; it probably should be willing to do > more of the work.) > > > Very old compilers don't support passing structs by value? > Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. > > > --- #line directives or not? --- > > > Third question that has been bugging me. > The C backend can output #line directives. > So you step through the Modula-3 source. What people expect. > This was working, and probably still does. > I turned it off subject to a constant in the backend. > Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) > > This is great for, during backend development/debugging, the C compiler gives me C line numbers. > If the backend worked perfectly, this would be pointless. > I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. > There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. > > > What to do to cater to both/everyone? > I wish I could have multiple #line directives: > #line 123 foo.m3.c 456 foo.m3 > > > but that doesn't exit. > I could encode information in the file name: > #line 123 "foo.m3.c/456 foo.m3" > > > but that is imperfect; error messages will be good, but debugging won't work > > > I could leave it as an #ifdef in the code. > I do not believe the following works: > > #ifndef CLINE > #define LINE(cline, cfile, m3line, m3file) cline cfile > #else > #define LINE(cline, cfile, m3line, m3file) m3line m3file > #endif > #line LINE(123, "foo.c", 456, "foo.m3") > > > but I'll try it. > > > I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: > #ifndef CLINE > #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) > #endif > > This is bloated, but might be best. > > > if "#define LINE" works, great, but I doubt it will. > > > --- typeindex besides typeid? --- > > > I'm now doing a lot of lookups of typeids. > It'd be super nice if the frontend also maintained "small" incrementing > typeIndices that I could use to index into an array. > > > set_type_count(typeCount:CARDINAL); (* maybe *) > declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); > > > and thereafter, use typeIndex instead of typeId, an index into an array. > > > I've been tempted to ask for just: > declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); > > > but I realize that preserving the structural hash id is likely too useful/important, > either now or hypothetically. > > > There is then the question as to if begin_unit/end_unit reset typeIndex. > This somewhat depends on how the frontend works. > > > At some point I'd like to try outputing one C file across multiple units, > and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, > M3CG.import_library(static | dynamic | unknown), > so the backend knows which units definitely link together, > and guide ELF visibility/__declspec(dllimport,dllexport). > > > Given that, typeIndices would not reset upon end_unit. > There are challenges here, e.g. separate/incremental compilation. > I would like to amortize C compiler startup, as well, all the type declarations > would be shared across units, so the overall C source smaller. > Computer memory is vastly larger today than when CM3 was written and compilation > strategies have shifted significantly toward "whole program compilation". > We could do similar in the C backend..or leave it to the C compiler to try. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 12 00:19:23 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Apr 2013 22:19:23 +0000 Subject: [M3devel] many matters big and small esp. wrt C backend In-Reply-To: <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> References: , <42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu> Message-ID: It is a mix of proposals and what-do-people-prefer-among-working-options andLet me try again. Just some of it. 1) Stronger typing on pop_param. Given INTERFACE I; PROCEDURE A(VAR a:INTEGER); PROCEDURE B() VAR b; BEGIN A(b); END B; I want void I__A(INTEGER* a); void I__B() { INTEGER b; A__I(&b) or A__I((INTEGER*)&b); } unnecessary casts are ok. This is not directly supported in M3CG: current: M3CG.pop_param(type := M3CG.Addr); (* Addr of what ? *) but it might be indirectly supported, i.e. if I look at the function type. Currently, on my machine, I cast to void*, but that isn't valid C++, only C. I might be able to cast the function itself to "untyped" and get away with it, but that is kind ugly too. proposal something like: M3CG.pop_param(CGType, TypeUID); but, furthermore, pop_struct doesn't need to be separate, so just: M3CG.pop_param(CGType, TypeUID, BitSize); and remove pop_struct. Much longer term, merely: M3CG.pop_param(TypeUID); suffices. CGType is generally redundant with TypeUIDs, however existing backends ignore TypeUIDs and get by with CGType. 2) Preference for how to handle passing structs by value in C backend? There are two obvious choices. I'm doing it "manually" because, perhaps, I didn't have good type information. I have good type information now, so I can use the C/C++ feature of passing structs by value, instead of passing a pointer and copying into a local. Works either way. No M3CG interface change. 3) Small dense TypeIndexes mostly-but-not-entirely in place of TypeUIDs. TypeUIDs imply a lot of "lookups" in the backend. Slow seeming. It'd be nice if we had a "linear" TypeIndex as well, that could be indices into a "full" array. Proposal: TypeIndex = CARDINAL; (* index into an array *) (* a separate typename here isn't all that valuable *) M3CG.declare_typeid or declare_typeindex or declare_type(TypeUID, TypeIndex); and possibly M3CG.declare_type_count(CARDINAL); (* maximum value of TypeIndex + 1, backends can allocate arrays of this size and the index by later TypeIndex *) TypeIndexes should take on the values roughly [0..N] where N is the number of types in the "program" (or unit..) and then replace TypeUID everywhere else with TypeIndex. Depending on how the frontend flows, it might not be able to compute TypeCount early enough. That is, I don't know if m3cg calls happen "during compilation" or only "at the end". As well, this does imply likely the same perf/lookups in the frontend. Moving rather than eliminating cost. However, it'd save it from multiple backends, and the frontend might already be paying this cost, I haven't looked yet. It is ok and works today, but I'd really rather have "small" dense integers that can index into an array than "random" integers that I'm forced to use something like a hash table or binary search a sorted array for. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu Subject: Re: [M3devel] many matters big and small esp. wrt C backend Date: Fri, 12 Apr 2013 07:12:42 +1000 To: jay.krell at cornell.edu Hi Jay, Is there any chance you could distill this stream of consciousness into an organized proposal of alternatives? I find it difficult to extract your precise proposals and arguments from this. --Tony Sent from my iPad On Apr 12, 2013, at 4:57 AM, Jay K wrote: The C/C++ works, for a while now, and is improving nicely (wrt debuggability). Here are some current problems/dilemnas. --- getting pointer parameters correctly typed esp. on passing side --- Up until now, any pointer parameter to a function has been typed as char*. (I have some preference for char* over void* because 1) it is valid pre-ANSI 2) you can do math on them; however given that char* is usually wrong, void* actually debugs better, showing nothing instead of garbage. gcc does allow math on void* but it is an extension -- http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer-Arith; I should probably use void* with gcc and wherever the extension is supported...autoconf...) Anyway.. Every pointer passed is cast to char*. This applies to VAR, READONLY, and records-by-value (more later). This works but is bad for debugging (again: void* is better than char*, but both are bad) I've been working on this. The interface to the backend is pop_param(cgtype) pop_struct(typeid, size) non-struct readonly and var parameters are just: pop_param(cgtype.addr) It would be nice if the frontend also passed a typeid here, and either using the typeid from a "declare_indirect" or "declare_pointer" or had separate booleans/flags for readonly/var. How about: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode); might as well merge this with pop_struct, no further change required probably. Or, at worst, another mode: TYPE ParameterMode = {Value (* or Normal or None? *), Var, ReadOnly, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or less abstract: TYPE ParameterMode = {Value, Pointer, StructByValue}; PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; mode: ParameterMode; bitSize: BitSize); or, again, if declare_indirect/declare_pointer is used to twiddle the typeuid, this suffices, I like it: (* bitSize, cgtype and typeid all imply size and agree, are somewhat redundant Backends without type checking can ignore typeid. e.g. NTx86.m3. bitSize is definitely redundant, but helps typeid-ignoring backends that implement struct-by-value themselves e.g. NTx86.m3 easily adapt. cgtype will be CGType.Addr for READONLY/VAR/ADDRESS/OBJECT/REF/TEXT, bitSize = sizeof(pointer) cgtype will be CGType.Struct for struct-by-value (size in bitSize) typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(cgtype: CGType; typeid: TypeUID; bitSize: BitSize); Ideally all backends would track typeids and it'd suffice to say: (* typeid will be declare_indirect/declare_pointer for READONLY/VAR (READONLY OBJECT?) typeid will NOT be to a declare_indirect/declare_pointer for struct-by-value *) PROCEDURE pop_param(typeid: TypeUID); but I don't see that happening soon. In reality, CGType could go away entirely. Not soon. (We'd need declare_integer(typeid, size, is_signed, is_word); declare_float(typeid, size), and maybe a few others for some pointer types..REFANY, TEXT, MUTEX, etc.) I haven't looked to see if this information (typeid/size for pop_param) is readily available in the frontend. I will do that soon. I have a few potential workarounds: cast to void* This appears to be working, with limited testing (my new test case, p254) Big drawback here is the code is no longer valid C++, only C. This is ok temporarily if I'm making improvements otherwise, but I really want to output valid C++. The function is still prototyped as taking stronger types, like INTEGER* or T1234* and C++ doesn't allow conversion from void* to other pointer types without a cast. Introspect on the function pointer type and cast appropriately, or even not at all. This should provide the ideal output and is probably viable. I'll look into it later. Cast the function to (*)(...) for C++ or (*)() for C. This is kind of gross. Hopefully it is not a deoptimization, but it might be. I already do such casting for indirect function calls, for reasons to do with the static link. I'm going to try this next. --- to depend on C passing/returning structs/records by value, or to do the copying ourselves? --- Now a minor dilemna, not a problem. Up until recently, I didn't have much type information flowing through the C backend. Or specifically I was only using CGType and not TypeUID. I'm now at the point where TypeUIDs and "almost everything" about them is kept track of. (just some loose ends maybe around opaque types and object runtime type information. I had known record sizes, but not fields. Maybe this was a dilemna already before. Anyway, the point is, up until now, record passing and returning by value I have handled internally by passing around pointers and making copies as needed (at function start). I forget exactly how returning works, I'll deal with that later. Passing works as follows: caller passes pointer to record callee has a local variable of that type callee early on copies pointer to local variable, and references that thereafter This works and has almost no downside. It is likely how the C compiler implements things anyway. Except maybe for "small" records/structs. Some calling conventions do allow for passing structs/records by value in registers. Passing structs/records by value is relatively rare, so we probably don't care much. Nevertheless, my question is, if I should go ahead and use the underlying C/C++ feature of passing structs by value? There are multiple choices: - no, leave it alone - yes, change it unconditionally - leave it as a const or var in M3C.m3 - make it #ifdefed in the output .c I think for returning, we have similar choices, but the frontend is willing to do the transform and currently does -- a matter of a boolean in Target.i3. This second question has equal quality debugging either way and needs no M3CG/frontend changes either way. (though, you know, frontend is willing to make more transforms for record return than record pass, I believe; it probably should be willing to do more of the work.) Very old compilers don't support passing structs by value? Or don't do it thread-safely, passing the value through a global? ORCA/C for Apple IIGS I think.. --- #line directives or not? --- Third question that has been bugging me. The C backend can output #line directives. So you step through the Modula-3 source. What people expect. This was working, and probably still does. I turned it off subject to a constant in the backend. Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) This is great for, during backend development/debugging, the C compiler gives me C line numbers. If the backend worked perfectly, this would be pointless. I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way. There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. What to do to cater to both/everyone? I wish I could have multiple #line directives: #line 123 foo.m3.c 456 foo.m3 but that doesn't exit. I could encode information in the file name: #line 123 "foo.m3.c/456 foo.m3" but that is imperfect; error messages will be good, but debugging won't work I could leave it as an #ifdef in the code. I do not believe the following works: #ifndef CLINE #define LINE(cline, cfile, m3line, m3file) cline cfile #else #define LINE(cline, cfile, m3line, m3file) m3line m3file #endif #line LINE(123, "foo.c", 456, "foo.m3") but I'll try it. I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: #ifndef CLINE #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *) #endif This is bloated, but might be best. if "#define LINE" works, great, but I doubt it will. --- typeindex besides typeid? --- I'm now doing a lot of lookups of typeids. It'd be super nice if the frontend also maintained "small" incrementing typeIndices that I could use to index into an array. set_type_count(typeCount:CARDINAL); (* maybe *) declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); and thereafter, use typeIndex instead of typeId, an index into an array. I've been tempted to ask for just: declare_object/pointer/indirect/record/etc.(typeIndex: CARDINAL; ...); but I realize that preserving the structural hash id is likely too useful/important, either now or hypothetically. There is then the question as to if begin_unit/end_unit reset typeIndex. This somewhat depends on how the frontend works. At some point I'd like to try outputing one C file across multiple units, and add M3CG.begin_library, M3CG.end_library, M3CG.begin_program, M3CG.end_program, M3CG.import_library(static | dynamic | unknown), so the backend knows which units definitely link together, and guide ELF visibility/__declspec(dllimport,dllexport). Given that, typeIndices would not reset upon end_unit. There are challenges here, e.g. separate/incremental compilation. I would like to amortize C compiler startup, as well, all the type declarations would be shared across units, so the overall C source smaller. Computer memory is vastly larger today than when CM3 was written and compilation strategies have shifted significantly toward "whole program compilation". We could do similar in the C backend..or leave it to the C compiler to try. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 02:48:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 11 Apr 2013 19:48:11 -0500 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <5165AB6E.8060808@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> Message-ID: <516759CB.4090101@lcwb.coop> After a small clarification to m3-defn-complete.tex, I reran the autogeneration that produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. Many of these are checked-in to CVS, even though mechanically generated. All the html files have many differences. The current checked-in files were built by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, which generates HTML 4.0 Transitional. This information is visible within the html files. In addition, there are many instances of a few kinds of tag changes. Anecdotal examination revealed no content changes. Does anybody have any problems with checking these new versions in? Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, the older html files in cm3/doc/reference, and what we see at the elegosoft website? If I check in the regenerated files into CVS, will they be seen on the website? From wagner at elegosoft.com Fri Apr 12 08:30:30 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 12 Apr 2013 08:30:30 +0200 Subject: [M3devel] Auto-generated html documentation and new tools In-Reply-To: <516759CB.4090101@lcwb.coop> References: <5165AB6E.8060808@lcwb.coop> <516759CB.4090101@lcwb.coop> Message-ID: <20130412083030.7ff717ea4e0bfad75a4625f3@elegosoft.com> On Thu, 11 Apr 2013 19:48:11 -0500 "Rodney M. Bates" wrote: > After a small clarification to m3-defn-complete.tex, I reran the autogeneration that > produces various alternate forms, e.g., .ps, .pdf. and single- and multi-page html. > Many of these are checked-in to CVS, even though mechanically generated. > > All the html files have many differences. The current checked-in files were built > by LaTex2HTML v2002-2.1 and generate HTML 3.2 Final. My computer has LaTex2HTML v2008, > which generates HTML 4.0 Transitional. This information is visible within the html files. > In addition, there are many instances of a few kinds of tag changes. Anecdotal examination > revealed no content changes. > > Does anybody have any problems with checking these new versions in? Just go ahead. > Also, what is the relationship between the autogenerated html files in cm3/doc/reference/complete/html, > the older html files in cm3/doc/reference, and what we see at the elegosoft website? I think reference/complete is just the language reference, while the level above contains additional information from Critical Mass about the system and libraries. > If I check > in the regenerated files into CVS, will they be seen on the website? There is a script ship-cm3-www-doc which needs to be run; I can do that for you. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Apr 12 09:57:33 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 07:57:33 +0000 Subject: [M3devel] trestle grandChild.init 5 parameters? Message-ID: can anyone explain this? PROCEDURE InitChild (j: Join; ch: VBT.T; p: DeleteProc)= VAR grandChild := NEW(GrandChild, proc := p); child := StableVBT.New(grandChild); BEGIN EVAL grandChild.init(ch); (* line 41 *) j.trueChild := ch; EVAL j.init(child) END InitChild; There are only two obvious parameters. The generated code passes 5. I understand they could be default parameters, but I still don't see it. My particular problem is that type 79A5AEBB and/or 23E73F69 isn't declared. I'd like to know what they are. If I don't know the full information for every struct passed by value at the point of the call, I won't be able to use the C/C++ feature of passing structs by value. //line 41 "../src/trestle/InstalledVBT.m3" /* start_call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_struct */ //line 41 "../src/trestle/InstalledVBT.m3" /* load_address */ //line 41 "../src/trestle/InstalledVBT.m3" /* pop_param */ //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /* check_nil */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_69_L_70))=(ADDRESS)(((ADDRESS)(L_67_L_68))); //line 41 "../src/trestle/InstalledVBT.m3" /* load */ //line 41 "../src/trestle/InstalledVBT.m3" /*check_nil*/if(!L_69_L_70)M_InstalledVBT_L_37_CRASH(1316); //line 41 "../src/trestle/InstalledVBT.m3" /* call_indirect */ //line 41 "../src/trestle/InstalledVBT.m3" /* store */ //line 41 "../src/trestle/InstalledVBT.m3" (*(ADDRESS*)(&L_65_L_66))=(ADDRESS)(((ADDRESS)(((ADDRESS (__cdecl*)(DOTDOTDOT))L_69_L_70)( grandChild_L_45, ch_L_48, ((T79A5AEBB*)(*((ADDRESS*)(INT64_(232)+((ADDRESS)(*((ADDRESS*)(INT64_(984)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), ((T23E73F69*)(*((ADDRESS*)(INT64_(120)+((ADDRESS)(*((ADDRESS*)(INT64_(1008)+((ADDRESS)(&M_InstalledVBT_L_37)))))))))), INT64_(72)+((ADDRESS)(&L_35_L_36)))))); -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 12 17:19:09 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:19:09 -0500 Subject: [M3devel] Another CVS problem: adding a new file Message-ID: <516825ED.9010003@lcwb.coop> m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. cvs checkout says: cvs server: cannot find module `m3-defn-complete.pdf' - ignored When I try to add it, cvs add says: cvs add: `m3-defn-complete.pdf' added independently by second party and when I try to commit, cvs says: cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' cvs [commit aborted]: correct above errors first! From rodney_bates at lcwb.coop Fri Apr 12 17:38:11 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 12 Apr 2013 10:38:11 -0500 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <516825ED.9010003@lcwb.coop> References: <516825ED.9010003@lcwb.coop> Message-ID: <51682A63.10709@lcwb.coop> On 04/12/2013 10:19 AM, Rodney M. Bates wrote: > m3-defn-complete.pdf is derived from m3-defn-complete.tex, but is not in the repository. > cvs checkout says: > > cvs server: cannot find module `m3-defn-complete.pdf' - ignored > > When I try to add it, cvs add says: > > cvs add: `m3-defn-complete.pdf' added independently by second party > > and when I try to commit, cvs says: > > cvs commit: use `cvs add' to create an entry for `m3-defn-complete.pdf' > cvs [commit aborted]: correct above errors first! > > And after the above, when I do cvs update on a different computer, cvs says: cvs update: move away `complete/m3-defn-complete.pdf'; it is in the way C complete/m3-defn-complete.pdf And there is indeed a local file by this name. But MORE CVS/Entries gives: /Makefile/1.2/Thu Apr 29 17:20:18 2010// /m3-defn-completeimg1.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /m3-defn-completeimg2.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /nx_grp_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /prev_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ /up_g.png/1.2/Thu Apr 29 17:20:18 2010/-kb/ D/html//// /m3-defn-complete.html/1.4/Fri Apr 12 15:23:26 2013// /m3-defn-complete.ps/1.5/Fri Apr 12 15:23:28 2013/-kb/ /m3-defn-complete.tex/1.22/Wed Apr 10 16:44:07 2013// But again, cvs log m3-defn-complete.pdf gives: RCS file: /usr/cvs/cm3/doc/reference/complete/m3-defn-complete.pdf,v Working file: complete/m3-defn-complete.pdf head: 1.3 branch: locks: strict access list: symbolic names: release_CM3_5_8_6: 1.1.2.4 release_CM3_5_8_RC5: 1.1.2.2 release_branch_cm3_5_8: 1.1.0.2 keyword substitution: b total revisions: 7; selected revisions: 7 description: ---------------------------- revision 1.3 date: 2010-04-29 12:20:18 -0500; author: wagner; state: Exp; lines: +1420 -1410; commitid: HFcCg3x7BkM9jQwu; merge doc changes/extensions from release_branch_cm3_5_8 ---------------------------- which appears to tell me it's in the head and several branches. From jay.krell at cornell.edu Fri Apr 12 17:33:44 2013 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Apr 2013 15:33:44 +0000 Subject: [M3devel] Another CVS problem: adding a new file In-Reply-To: <516825ED.9010003@lcwb.coop> References: <516825ED.9010003@lcwb.coop> Message-ID: CVS is awful. Try this: make sure you have "everything" "backed up" esp. m3-defn-complete.pdf rm -rf the local directory with m3-defn-complete.pdf (that yo