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 <darko at darko.org> escribi?:

De: Darko <darko at darko.org>
Asunto: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/237cc323/attachment.html>

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. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>, "Darko" <darko at darko.org>
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 <darko at darko.org> escribi?:

De: Darko <darko at darko.org>
Asunto: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/5d41fe58/attachment.html>

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: <COL002-W9207521A95605B20119568E6DF0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/eeec11f3/attachment.html>

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: <COL002-W9207521A95605B20119568E6DF0@phx.gbl>
References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org>
	<COL002-W9207521A95605B20119568E6DF0@phx.gbl>
Message-ID: <B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130401/65e234fc/attachment.html>

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: <COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/d6a6f318/attachment.html>

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>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>,
	<3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org>
Message-ID: <COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>

 > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/39d786b9/attachment.html>

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: <COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/00df58d6/attachment.html>

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: <COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>
References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
	<3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org>
	<COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>
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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/ea047637/attachment.html>

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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>
References: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/fc009799/attachment.html>

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: <B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@darko.org>
References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org>
	<COL002-W9207521A95605B20119568E6DF0@phx.gbl>
	<B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@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
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-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.<div><br></div><div><br><div><div>On Apr 1, 2013, at 9:22 PM, Jay K =
>wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
>type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
>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; "><div =
>class=3D"hmmessage" style=3D"font-size: 12pt; font-family: Calibri; =
>"><div dir=3D"ltr">External debuggers are good. Have you used Visual =
>Studio much?<br>Generate the right debug information and we get =
>excellent working debuggers that people put a lot of time and work =
>into.<br><br><br>On the other hand, I do understand your notion of =
>"internal debugger" and agree it is a good approach.<br><br><br>&nbsp;- =
>Jay<br><br><br><br><div><div id=3D"SkyDrivePlaceholder"></div>&gt; =
>From:<span class=3D"Apple-converted-space">&nbsp;</span><a =
>href=3D"mailto:darko at darko.org">darko at darko.org</a><br>&gt; Date: Mon, 1 =
>Apr 2013 14:53:37 -0700<br>&gt; To:<span =
>class=3D"Apple-converted-space">&nbsp;</span><a =
>href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com</a><br>&gt; =
>Subject: [M3devel] Why do we need external debugging?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; 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?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; 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.<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; Am I the only one =
>who thinks this?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; - =
>Darko<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br></div></div></div></span>=
></blockquote></div><br></div></body></html>=
>
>--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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/d8154f1a/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/d8154f1a/attachment.sig>

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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>,
	<3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org>
Message-ID: <COL002-W630592CD92EA402C15F4EFE6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/be9866da/attachment.html>

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: <COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/17eb5aef/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: utf8.c
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/17eb5aef/attachment.c>

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: <COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>
References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org>
	<COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>
Message-ID: <C7350F98-1506-4D27-A17C-D78780F493A8@m3w.org>

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
> 
> 
> 
> <utf8.c>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130404/a76eafe6/attachment.html>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/f97d8648/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/f97d8648/attachment.sig>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
References: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
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
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-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?<div><br></div><div><div>new source -&gt; =
>compiling XLModule.m3</div><div>"../src/XLModule.m3", line 181: NARROW: =
>types must be assignable</div><div>"../src/XLModule.m3", line 239: =
>incompatible types (x)</div></div><div><br></div><div>Second one is =
>RefSeq.T.addhi(procedureType)</div><div><br></div><div>TIA,</div><div>dd</=
>div><div><div apple-content-edited=3D"true">
><span class=3D"Apple-style-span" style=3D"font-family: Helvetica; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; =
>"><div>--</div></div></span></div></span><span class=3D"Apple-style-span" =
>style=3D"font-family: Helvetica; ">Dragi=C5=A1a Duri=C4=87</span><span =
>class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><div><a =
>href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org</a></div><div><br></div>=
></div></span></div></span><br class=3D"Apple-interchange-newline">
></div>
><br></div></body></html>=
>
>--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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/ff1f8a5d/attachment.html>

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: <COL125-W460B9D1DBA8F4A20F9C4C6E6DB0@phx.gbl>


> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/7e18ad32/attachment.html>

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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/faa63519/attachment.html>

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: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/090bb91a/attachment.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/03bb17fa/attachment.html>

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: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>
References: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>
Message-ID: <DE057DD1-657A-4416-BFFC-CBCDBD37481E@cs.purdue.edu>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/d6f89982/attachment.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
	<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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/3f072b33/attachment.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
References: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
References: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
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 <mailto: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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/217cef9b/attachment.html>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
	<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 <mailto: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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
	<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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>,
	<51619569.4070202@lcwb.coop>
Message-ID: <COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/1a8951d1/attachment.html>

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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>,
	<516198AB.5040509@lcwb.coop>,
	<20130407183746.GB24973@topoi.pooq.com>
Message-ID: <COL125-W43C2A24CADBFC0D73FCB2BE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/12ca60bb/attachment.html>

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: <COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>,
	<51619569.4070202@lcwb.coop>
	<COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
Message-ID: <DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/3914a798/attachment.html>

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: <DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
	<51619569.4070202@lcwb.coop>
	<COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
	<DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>
Message-ID: <D10AB51D-53EC-476D-81D4-62E23A91118E@gmail.com>

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 <dmuysers at hotmail.com> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/af1d20cd/attachment.html>

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: <COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/a7ae8127/attachment.html>

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: <COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>
References: <20130408183918.555525DEA9D@birch.elegosoft.com>
	<COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>
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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/48f717cd/attachment.html>

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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>
References: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/7119ff90/attachment.html>

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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>,
	<42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu>
Message-ID: <COL125-W3209FFD59FB5FA139464F5E6C70@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/15ebe9ef/attachment.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>

  
  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 <stdio.h> 
 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/1d4aae2c/attachment.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>
References: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>
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 <jay.krell at cornell.edu> 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 <stdio.h> 
>  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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/4802481d/attachment.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>,
	<06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu>
Message-ID: <COL125-W44460FD17490ADE9571C27E6C00@phx.gbl>

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 <jay.krell at cornell.edu> 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 <stdio.h> 
 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/94639418/attachment.html>

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: <COL125-W25430683673CC692BCD91DE6C00@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/9d59ee77/attachment.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/f2e41dce/attachment.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/37fa075e/attachment.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>,
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>
Message-ID: <COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/61ceec09/attachment.html>

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" <rodney_bates at lcwb.coop> 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: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/326d259d/attachment.html>

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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/68e4af1a/attachment.html>

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: <COL125-W2220B0DBBD27BC751336B2E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/1c497771/attachment.html>

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" <rodney_bates at lcwb.coop> 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: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>
References: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>
Message-ID: <COL125-W419A0D69A6F503301FD15AE6C20@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/70931956/attachment.html>

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: <COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>, ,
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>,
	<COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
Message-ID: <COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>

  >  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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/40f61c0a/attachment.html>

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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
Message-ID: <B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/7ab70a40/attachment.html>

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" <rodney_bates at lcwb.coop> wrote:

> On 04/12/2013 01:30 AM, Olaf Wagner wrote:
> > On Thu, 11 Apr 2013 19:48:11 -0500
> > "Rodney M. Bates" <rodney_bates at lcwb.coop> 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: <COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>
	<COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
	<COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>
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: <B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
	<B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
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>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
	<B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/ad6a9379/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/0155dced/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/0155dced/attachment.sig>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/ff950909/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/41740f65/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/41740f65/attachment.sig>

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<mailto:dragisha at m3w.org>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/9710fd58/attachment.html>

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: <COL125-W297E6079717EA93196445AE6CD0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/c1fbdc08/attachment.html>

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: <C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/3e77aa77/attachment.html>

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: <COL125-W297E6079717EA93196445AE6CD0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL>
	<COL125-W297E6079717EA93196445AE6CD0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/30c58251/attachment.html>

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: <C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL>
	<C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>
Message-ID: <F39F129F-63BF-4D97-A38B-D140223CA65D@m3w.org>


--
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/d57eb744/attachment.html>

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: <CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>

On Wed, Feb 6, 2013 at 4:38 PM, Olaf Wagner <wagner at elegosoft.com> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/cd30ec59/attachment.html>

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: <CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL><00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu><51126B00.7010301@columbus.rr.com><20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com>
	<CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>
Message-ID: <DUB123-DS147CC46CF745D3765092DCDDCD0@phx.gbl>

...at least for Linux and FreeBSD,...

and for Windows nobody cares even a bit!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/66576caf/attachment.html>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
Message-ID: <COL125-W26FFB529DF12F6F2D8BDA8E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/1c9ead92/attachment.html>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
Message-ID: <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/4f243eb7/attachment.html>

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: <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, ,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>,
	<COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>
Message-ID: <COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/bd4ba51a/attachment.html>

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: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/92fcfe7a/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/92fcfe7a/attachment.sig>

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: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
References: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
Message-ID: <COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/e0afd277/attachment.html>

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: <COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	, , <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>, ,
	<COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>,
	<COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>
Message-ID: <COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/756c6832/attachment.html>

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: <COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>
References: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
	<COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/6c783ea2/attachment.html>

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<mailto:dragisha at m3w.org>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/558c9408/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130418/58488436/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130418/58488436/attachment.sig>

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: <COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,,, ,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>,
	, , <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>, ,
	<COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>,
	<COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>
Message-ID: <COL125-W45AED01E47C2A01D881B1AE6C80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130419/a09492f0/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/dc2f2e58/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/dc2f2e58/attachment.sig>

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: <B82932CC-EEEA-48F7-B73F-E80A3D451262@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/b0f0b8ec/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/b0f0b8ec/attachment.sig>

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: <B88E1F85-C3CA-4984-98A9-FBE2260DF392@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/cccd7c70/attachment.html>

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: <COL125-W34743F971FA87AB3E6743DE6C90@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/4c73c99d/attachment.html>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/a790221a/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/651a4e41/attachment.html>

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: <CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/4a89abcd/attachment.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/006e61ff/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/006e61ff/attachment.sig>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/2cb0db38/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/2cb0db38/attachment.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/4190d521/attachment.html>

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: <COL125-W5EEA2B8A1431DC17C2BDFE6CA0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/3ae238bc/attachment.html>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
Message-ID: <20130421234903.fbc4837a0cba1f1c28ebc2d7@elegosoft.com>

On Sun, 21 Apr 2013 20:55:43 +0000
Jay K <jay.krell at cornell.edu> 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: <F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/0553c792/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/0553c792/attachment.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
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: <CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org>
	<20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com>
	<1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org>
	<CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
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 <peter.mckinna at gmail.com> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/58ce8168/attachment.html>

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>
	<CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
	<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 <peter.mckinna at gmail.com> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/b4c45f85/attachment.html>

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: <F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/26740f5a/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/26740f5a/attachment.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
Message-ID: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/dbc9b338/attachment.html>

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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
Message-ID: <F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/7302e3f8/attachment.html>

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: <F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>
Message-ID: <FDCEB4B7-6493-40E5-8723-2CCA445B3DCE@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/015164c4/attachment.html>

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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
Message-ID: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/c5ff907b/attachment.html>

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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
Message-ID: <COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>

 > 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/b5073b54/attachment.html>

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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
Message-ID: <C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/45562b21/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/45562b21/attachment.sig>

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: <C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
Message-ID: <COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/6747d2aa/attachment.html>

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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
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 <jay.krell at cornell.edu> 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
>
><div dir=3D"ltr">There&#39;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&#39;s =
>sometimes called the &quot;absurd&quot; type).</div>
><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Apr 2=
>2, 2013 at 10:38 AM, Jay K <span dir=3D"ltr">&lt;<a href=3D"mailto:jay.krel=
>l at cornell.edu" target=3D"_blank">jay.krell at cornell.edu</a>&gt;</span> wrote=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
>ft:1px #ccc solid;padding-left:1ex">
>
>
>
><div><div dir=3D"ltr">Disclosure: I knew they are of type &quot;NULL&quot;,=
> but I didn&#39;t/don&#39;t know what that type is, or have a mental model =
>for it.<br>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&quot;ADDRESS&quot; presumably. Checks that it is NI=
>L, that is the frontend&#39;s job. The error is just that I check that I kn=
>ow about every type. Some types are &quot;predeclared&quot;, some come from=
> the frontend. I&#39;ll predeclare this. Arguably nothing should be predecl=
>ared.<br>
>=A0<br>=A0<br>=A0=A0- Jay<br>=A0<br><div><div></div>&gt; Date: Sun, 21 Apr =
>2013 21:03:02 -0500<br>&gt; From: <a href=3D"mailto:rodney_bates at lcwb.coop"=
> target=3D"_blank">rodney_bates at lcwb.coop</a><br>&gt; To: <a href=3D"mailto=
>:m3devel at elegosoft.com" target=3D"_blank">m3devel at elegosoft.com</a><br>
>&gt; Subject: Re: [M3devel] null type?<div><div class=3D"h5"><br>&gt; <br>&=
>gt; <br>&gt; <br>&gt; On 04/21/2013 03:55 PM, Jay K wrote:<br>&gt; &gt; Wha=
>t is the meaning of this:<br>&gt; &gt;<br>&gt; &gt; cm3/elego/graphicutils/=
>src/RsrcFilter<br>
>&gt; &gt;<br>&gt; &gt;      init(p1, p2, p3, p4, p5, p6 :=3D NIL) : T;<br>&=
>gt; &gt;      (* Initializes the resource search path. *)<br>&gt; &gt;<br>&=
>gt; &gt;<br>&gt; &gt; PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 :=3D =
>NIL) : T =3D<br>
>&gt; &gt;<br>&gt; <br>&gt; Modula-3 says:<br>&gt; <br>&gt; 2.2.7: &#39;The =
>following reference types are predeclared:<br>&gt;          ...<br>&gt;    =
>      NULL   Contains only NIL&#39;<br>&gt; <br>&gt; And:<br>&gt; <br>&gt; =
>2.2.8: &#39;A formal parameter declaration has the form<br>
>&gt;            Mode Name: Type :=3D Default<br>&gt;          ...<br>&gt;  =
>        If Type is omitted, it is taken to be the type of Default.&#39;<br>=
>&gt; <br>&gt; And:<br>&gt; <br>&gt; 2.6.6: &#39;The literal &quot;NIL&quot;=
> denotes the value NIL.  Its type is NULL.&#39;<br>
>&gt; <br>&gt; So all the pi&#39;s have type NULL, and only NIL can be passe=
>d to them<br>&gt; as actuals.   That&#39;s what the language says.  It look=
>s like the code<br>&gt; in Init thinks it can get non-NIL reference values,=
> but an attempt to pass<br>
>&gt; one in a call should fail a runtime assignability check, since it<br>&=
>gt; won&#39;t be a member of NULL.<br>&gt; <br>&gt; When Init passes one of=
> these to Convert (Yes, I peeked into<br>&gt; RsrcFilter.m3), it is assigna=
>ble, with no runtime check.  Convert<br>
>&gt; thinks it has a REFANY, and other calls to Convert could indeed<br>&gt=
>; give it something non-NIL, but not from the calls in Init.<br>&gt; <br>&g=
>t; Of course, unsafe code could probably LOOPHOLE (remember, any word<br>
>&gt; can be verbed) something non-NIL to NULL and pass it to init/Init.<br>=
>&gt; If the compiler did the most obvious thing, this might do what was<br>=
>&gt; apparently intended.<br>&gt; <br>&gt; But then again, a compiler would=
> be fully compliant with the language<br>
>&gt; and perfectly within its rights to optimize out such a parameter,<br>&=
>gt; not actually pass it at runtime at all, and just insert constant NIL<br=
>>&gt; wherever the formal was referenced in the body of Init, thus undermin=
>ing<br>
>&gt; the above intent.<br>&gt; <br>&gt; Which makes for a good example of h=
>ow unsafe code (almost?) always<br>&gt; depends on assumptions about what a=
> compiler will do.<br>&gt; <br>&gt; &gt;<br>&gt; &gt; What are the types of=
> p1, p2, etc.?<br>
>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;   - Jay<br>&gt; <br></div></div></div> =
>		 	   		  </div></div>
></blockquote></div><br></div>
>
>--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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
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: <COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/de25268a/attachment.html>

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>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
Message-ID: <F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/8eefc33b/attachment.html>

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: <E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/f5c3a95f/attachment.html>

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: <F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
Message-ID: <E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/bf7e46d6/attachment.html>

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>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
Message-ID: <B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/16d1bf17/attachment.html>

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: <COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/893ed250/attachment.html>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<20130424030938.GA32407@topoi.pooq.com>
Message-ID: <CBBD126A-E22D-446F-A7DF-22C57891BB0B@darko.org>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>

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: <B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
Message-ID: <D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/54cbf25c/attachment.html>

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: <D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
Message-ID: <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com>

On Thu, 25 Apr 2013 07:38:46 +0200
Dragi?a Duri? <dragisha at m3w.org> 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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/975dfc96/attachment.html>

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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@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? <dragisha at m3w.org> 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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
	<20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com>
	<743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org>
	<20130425092740.55bf536a.wagner@elego.de>
Message-ID: <BA56767B-989B-4AC6-9282-B0719E575058@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/eb5a4e3d/attachment.html>

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: <EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>

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" <hendrik at topoi.pooq.com>
Sent: Thursday, April 25, 2013 8:13 PM
To: <m3devel at elegosoft.com>
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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
References: <20130425181303.GA31005@topoi.pooq.com>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/56eab511/attachment.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org>
Message-ID: <DUB123-DS139DB721A365212A6D9327DDB70@phx.gbl>

>> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/3559ed62/attachment.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/148fbf07/attachment.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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? <dragisha at m3w.org> 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: <CC205D88-7E0E-40F3-BAB4-656661B24497@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130428/2dcc99ac/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130428/2dcc99ac/attachment.sig>

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: <E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.com>

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" <rodney at elego.de> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/b8f35830/attachment.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/b8f35830/attachment.sig>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/d033aec3/attachment.html>

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 <hosking at cs.purdue.edu>
> Date: 30 April 2013 5:21:50 PM AEST
> To: Dragi?a Duri? <dragisha at m3w.org>
> Cc: m3devel developers <m3devel at elegosoft.com>
> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/e9e7769a/attachment.html>

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: <E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.com>
References: <20130428190606.3DF769BA007@birch.elegosoft.com>
	<E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.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" <rodney at elego.de> 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 <darko at darko.org> escribi?:

De: Darko <darko at darko.org>
Asunto: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/237cc323/attachment-0001.html>

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. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>, "Darko" <darko at darko.org>
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 <darko at darko.org> escribi?:

De: Darko <darko at darko.org>
Asunto: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/5d41fe58/attachment-0001.html>

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: <COL002-W9207521A95605B20119568E6DF0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/eeec11f3/attachment-0001.html>

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: <COL002-W9207521A95605B20119568E6DF0@phx.gbl>
References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org>
	<COL002-W9207521A95605B20119568E6DF0@phx.gbl>
Message-ID: <B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130401/65e234fc/attachment-0001.html>

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: <COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/d6a6f318/attachment-0001.html>

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>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>,
	<3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org>
Message-ID: <COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>

 > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/39d786b9/attachment-0001.html>

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: <COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/00df58d6/attachment-0001.html>

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: <COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>
References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
	<3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org>
	<COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>
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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/ea047637/attachment-0001.html>

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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>
References: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/fc009799/attachment-0001.html>

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: <B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@darko.org>
References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org>
	<COL002-W9207521A95605B20119568E6DF0@phx.gbl>
	<B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@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
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-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.<div><br></div><div><br><div><div>On Apr 1, 2013, at 9:22 PM, Jay K =
>wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
>type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
>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; "><div =
>class=3D"hmmessage" style=3D"font-size: 12pt; font-family: Calibri; =
>"><div dir=3D"ltr">External debuggers are good. Have you used Visual =
>Studio much?<br>Generate the right debug information and we get =
>excellent working debuggers that people put a lot of time and work =
>into.<br><br><br>On the other hand, I do understand your notion of =
>"internal debugger" and agree it is a good approach.<br><br><br>&nbsp;- =
>Jay<br><br><br><br><div><div id=3D"SkyDrivePlaceholder"></div>&gt; =
>From:<span class=3D"Apple-converted-space">&nbsp;</span><a =
>href=3D"mailto:darko at darko.org">darko at darko.org</a><br>&gt; Date: Mon, 1 =
>Apr 2013 14:53:37 -0700<br>&gt; To:<span =
>class=3D"Apple-converted-space">&nbsp;</span><a =
>href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com</a><br>&gt; =
>Subject: [M3devel] Why do we need external debugging?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; 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?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; 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.<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; Am I the only one =
>who thinks this?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; - =
>Darko<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br></div></div></div></span>=
></blockquote></div><br></div></body></html>=
>
>--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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/d8154f1a/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/d8154f1a/attachment-0001.sig>

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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>,
	<3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org>
Message-ID: <COL002-W630592CD92EA402C15F4EFE6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/be9866da/attachment-0001.html>

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: <COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/17eb5aef/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: utf8.c
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/17eb5aef/attachment-0001.c>

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: <COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>
References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org>
	<COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>
Message-ID: <C7350F98-1506-4D27-A17C-D78780F493A8@m3w.org>

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
> 
> 
> 
> <utf8.c>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130404/a76eafe6/attachment-0001.html>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/f97d8648/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/f97d8648/attachment-0001.sig>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
References: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
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
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-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?<div><br></div><div><div>new source -&gt; =
>compiling XLModule.m3</div><div>"../src/XLModule.m3", line 181: NARROW: =
>types must be assignable</div><div>"../src/XLModule.m3", line 239: =
>incompatible types (x)</div></div><div><br></div><div>Second one is =
>RefSeq.T.addhi(procedureType)</div><div><br></div><div>TIA,</div><div>dd</=
>div><div><div apple-content-edited=3D"true">
><span class=3D"Apple-style-span" style=3D"font-family: Helvetica; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; =
>"><div>--</div></div></span></div></span><span class=3D"Apple-style-span" =
>style=3D"font-family: Helvetica; ">Dragi=C5=A1a Duri=C4=87</span><span =
>class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><div><a =
>href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org</a></div><div><br></div>=
></div></span></div></span><br class=3D"Apple-interchange-newline">
></div>
><br></div></body></html>=
>
>--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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/ff1f8a5d/attachment-0001.html>

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: <COL125-W460B9D1DBA8F4A20F9C4C6E6DB0@phx.gbl>


> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/7e18ad32/attachment-0001.html>

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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/faa63519/attachment-0001.html>

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: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/090bb91a/attachment-0001.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/03bb17fa/attachment-0001.html>

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: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>
References: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>
Message-ID: <DE057DD1-657A-4416-BFFC-CBCDBD37481E@cs.purdue.edu>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/d6f89982/attachment-0001.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
	<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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/3f072b33/attachment-0001.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
References: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
References: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
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 <mailto: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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/217cef9b/attachment-0001.html>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
	<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 <mailto: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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
	<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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>,
	<51619569.4070202@lcwb.coop>
Message-ID: <COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/1a8951d1/attachment-0001.html>

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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>,
	<516198AB.5040509@lcwb.coop>,
	<20130407183746.GB24973@topoi.pooq.com>
Message-ID: <COL125-W43C2A24CADBFC0D73FCB2BE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/12ca60bb/attachment-0001.html>

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: <COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>,
	<51619569.4070202@lcwb.coop>
	<COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
Message-ID: <DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/3914a798/attachment-0001.html>

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: <DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
	<51619569.4070202@lcwb.coop>
	<COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
	<DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>
Message-ID: <D10AB51D-53EC-476D-81D4-62E23A91118E@gmail.com>

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 <dmuysers at hotmail.com> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/af1d20cd/attachment-0001.html>

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: <COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/a7ae8127/attachment-0001.html>

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: <COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>
References: <20130408183918.555525DEA9D@birch.elegosoft.com>
	<COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>
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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/48f717cd/attachment-0001.html>

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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>
References: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/7119ff90/attachment-0001.html>

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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>,
	<42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu>
Message-ID: <COL125-W3209FFD59FB5FA139464F5E6C70@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/15ebe9ef/attachment-0001.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>

  
  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 <stdio.h> 
 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/1d4aae2c/attachment-0001.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>
References: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>
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 <jay.krell at cornell.edu> 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 <stdio.h> 
>  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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/4802481d/attachment-0001.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>,
	<06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu>
Message-ID: <COL125-W44460FD17490ADE9571C27E6C00@phx.gbl>

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 <jay.krell at cornell.edu> 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 <stdio.h> 
 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/94639418/attachment-0001.html>

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: <COL125-W25430683673CC692BCD91DE6C00@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/9d59ee77/attachment-0001.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/f2e41dce/attachment-0001.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/37fa075e/attachment-0001.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>,
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>
Message-ID: <COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/61ceec09/attachment-0001.html>

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" <rodney_bates at lcwb.coop> 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: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/326d259d/attachment-0001.html>

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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/68e4af1a/attachment-0001.html>

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: <COL125-W2220B0DBBD27BC751336B2E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/1c497771/attachment-0001.html>

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" <rodney_bates at lcwb.coop> 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: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>
References: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>
Message-ID: <COL125-W419A0D69A6F503301FD15AE6C20@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/70931956/attachment-0001.html>

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: <COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>, ,
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>,
	<COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
Message-ID: <COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>

  >  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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/40f61c0a/attachment-0001.html>

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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
Message-ID: <B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/7ab70a40/attachment-0001.html>

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" <rodney_bates at lcwb.coop> wrote:

> On 04/12/2013 01:30 AM, Olaf Wagner wrote:
> > On Thu, 11 Apr 2013 19:48:11 -0500
> > "Rodney M. Bates" <rodney_bates at lcwb.coop> 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: <COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>
	<COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
	<COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>
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: <B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
	<B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
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>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
	<B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/ad6a9379/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/0155dced/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/0155dced/attachment-0001.sig>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/ff950909/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/41740f65/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/41740f65/attachment-0001.sig>

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<mailto:dragisha at m3w.org>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/9710fd58/attachment-0001.html>

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: <COL125-W297E6079717EA93196445AE6CD0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/c1fbdc08/attachment-0001.html>

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: <C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/3e77aa77/attachment-0001.html>

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: <COL125-W297E6079717EA93196445AE6CD0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL>
	<COL125-W297E6079717EA93196445AE6CD0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/30c58251/attachment-0001.html>

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: <C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL>
	<C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>
Message-ID: <F39F129F-63BF-4D97-A38B-D140223CA65D@m3w.org>


--
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/d57eb744/attachment-0001.html>

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: <CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>

On Wed, Feb 6, 2013 at 4:38 PM, Olaf Wagner <wagner at elegosoft.com> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/cd30ec59/attachment-0001.html>

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: <CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL><00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu><51126B00.7010301@columbus.rr.com><20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com>
	<CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>
Message-ID: <DUB123-DS147CC46CF745D3765092DCDDCD0@phx.gbl>

...at least for Linux and FreeBSD,...

and for Windows nobody cares even a bit!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/66576caf/attachment-0001.html>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
Message-ID: <COL125-W26FFB529DF12F6F2D8BDA8E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/1c9ead92/attachment-0001.html>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
Message-ID: <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/4f243eb7/attachment-0001.html>

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: <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, ,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>,
	<COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>
Message-ID: <COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/bd4ba51a/attachment-0001.html>

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: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/92fcfe7a/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/92fcfe7a/attachment-0001.sig>

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: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
References: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
Message-ID: <COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/e0afd277/attachment-0001.html>

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: <COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	, , <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>, ,
	<COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>,
	<COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>
Message-ID: <COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/756c6832/attachment-0001.html>

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: <COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>
References: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
	<COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/6c783ea2/attachment-0001.html>

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<mailto:dragisha at m3w.org>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/558c9408/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130418/58488436/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130418/58488436/attachment-0001.sig>

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: <COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,,, ,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>,
	, , <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>, ,
	<COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>,
	<COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>
Message-ID: <COL125-W45AED01E47C2A01D881B1AE6C80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130419/a09492f0/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/dc2f2e58/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/dc2f2e58/attachment-0001.sig>

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: <B82932CC-EEEA-48F7-B73F-E80A3D451262@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/b0f0b8ec/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/b0f0b8ec/attachment-0001.sig>

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: <B88E1F85-C3CA-4984-98A9-FBE2260DF392@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/cccd7c70/attachment-0001.html>

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: <COL125-W34743F971FA87AB3E6743DE6C90@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/4c73c99d/attachment-0001.html>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/a790221a/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/651a4e41/attachment-0001.html>

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: <CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/4a89abcd/attachment-0001.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/006e61ff/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/006e61ff/attachment-0001.sig>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/2cb0db38/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/2cb0db38/attachment-0001.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/4190d521/attachment-0001.html>

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: <COL125-W5EEA2B8A1431DC17C2BDFE6CA0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/3ae238bc/attachment-0001.html>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
Message-ID: <20130421234903.fbc4837a0cba1f1c28ebc2d7@elegosoft.com>

On Sun, 21 Apr 2013 20:55:43 +0000
Jay K <jay.krell at cornell.edu> 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: <F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/0553c792/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/0553c792/attachment-0001.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
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: <CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org>
	<20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com>
	<1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org>
	<CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
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 <peter.mckinna at gmail.com> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/58ce8168/attachment-0001.html>

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>
	<CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
	<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 <peter.mckinna at gmail.com> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/b4c45f85/attachment-0001.html>

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: <F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/26740f5a/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/26740f5a/attachment-0001.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
Message-ID: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/dbc9b338/attachment-0001.html>

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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
Message-ID: <F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/7302e3f8/attachment-0001.html>

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: <F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>
Message-ID: <FDCEB4B7-6493-40E5-8723-2CCA445B3DCE@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/015164c4/attachment-0001.html>

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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
Message-ID: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/c5ff907b/attachment-0001.html>

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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
Message-ID: <COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>

 > 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/b5073b54/attachment-0001.html>

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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
Message-ID: <C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/45562b21/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/45562b21/attachment-0001.sig>

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: <C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
Message-ID: <COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/6747d2aa/attachment-0001.html>

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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
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 <jay.krell at cornell.edu> 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
>
><div dir=3D"ltr">There&#39;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&#39;s =
>sometimes called the &quot;absurd&quot; type).</div>
><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Apr 2=
>2, 2013 at 10:38 AM, Jay K <span dir=3D"ltr">&lt;<a href=3D"mailto:jay.krel=
>l at cornell.edu" target=3D"_blank">jay.krell at cornell.edu</a>&gt;</span> wrote=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
>ft:1px #ccc solid;padding-left:1ex">
>
>
>
><div><div dir=3D"ltr">Disclosure: I knew they are of type &quot;NULL&quot;,=
> but I didn&#39;t/don&#39;t know what that type is, or have a mental model =
>for it.<br>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&quot;ADDRESS&quot; presumably. Checks that it is NI=
>L, that is the frontend&#39;s job. The error is just that I check that I kn=
>ow about every type. Some types are &quot;predeclared&quot;, some come from=
> the frontend. I&#39;ll predeclare this. Arguably nothing should be predecl=
>ared.<br>
>=A0<br>=A0<br>=A0=A0- Jay<br>=A0<br><div><div></div>&gt; Date: Sun, 21 Apr =
>2013 21:03:02 -0500<br>&gt; From: <a href=3D"mailto:rodney_bates at lcwb.coop"=
> target=3D"_blank">rodney_bates at lcwb.coop</a><br>&gt; To: <a href=3D"mailto=
>:m3devel at elegosoft.com" target=3D"_blank">m3devel at elegosoft.com</a><br>
>&gt; Subject: Re: [M3devel] null type?<div><div class=3D"h5"><br>&gt; <br>&=
>gt; <br>&gt; <br>&gt; On 04/21/2013 03:55 PM, Jay K wrote:<br>&gt; &gt; Wha=
>t is the meaning of this:<br>&gt; &gt;<br>&gt; &gt; cm3/elego/graphicutils/=
>src/RsrcFilter<br>
>&gt; &gt;<br>&gt; &gt;      init(p1, p2, p3, p4, p5, p6 :=3D NIL) : T;<br>&=
>gt; &gt;      (* Initializes the resource search path. *)<br>&gt; &gt;<br>&=
>gt; &gt;<br>&gt; &gt; PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 :=3D =
>NIL) : T =3D<br>
>&gt; &gt;<br>&gt; <br>&gt; Modula-3 says:<br>&gt; <br>&gt; 2.2.7: &#39;The =
>following reference types are predeclared:<br>&gt;          ...<br>&gt;    =
>      NULL   Contains only NIL&#39;<br>&gt; <br>&gt; And:<br>&gt; <br>&gt; =
>2.2.8: &#39;A formal parameter declaration has the form<br>
>&gt;            Mode Name: Type :=3D Default<br>&gt;          ...<br>&gt;  =
>        If Type is omitted, it is taken to be the type of Default.&#39;<br>=
>&gt; <br>&gt; And:<br>&gt; <br>&gt; 2.6.6: &#39;The literal &quot;NIL&quot;=
> denotes the value NIL.  Its type is NULL.&#39;<br>
>&gt; <br>&gt; So all the pi&#39;s have type NULL, and only NIL can be passe=
>d to them<br>&gt; as actuals.   That&#39;s what the language says.  It look=
>s like the code<br>&gt; in Init thinks it can get non-NIL reference values,=
> but an attempt to pass<br>
>&gt; one in a call should fail a runtime assignability check, since it<br>&=
>gt; won&#39;t be a member of NULL.<br>&gt; <br>&gt; When Init passes one of=
> these to Convert (Yes, I peeked into<br>&gt; RsrcFilter.m3), it is assigna=
>ble, with no runtime check.  Convert<br>
>&gt; thinks it has a REFANY, and other calls to Convert could indeed<br>&gt=
>; give it something non-NIL, but not from the calls in Init.<br>&gt; <br>&g=
>t; Of course, unsafe code could probably LOOPHOLE (remember, any word<br>
>&gt; can be verbed) something non-NIL to NULL and pass it to init/Init.<br>=
>&gt; If the compiler did the most obvious thing, this might do what was<br>=
>&gt; apparently intended.<br>&gt; <br>&gt; But then again, a compiler would=
> be fully compliant with the language<br>
>&gt; and perfectly within its rights to optimize out such a parameter,<br>&=
>gt; not actually pass it at runtime at all, and just insert constant NIL<br=
>>&gt; wherever the formal was referenced in the body of Init, thus undermin=
>ing<br>
>&gt; the above intent.<br>&gt; <br>&gt; Which makes for a good example of h=
>ow unsafe code (almost?) always<br>&gt; depends on assumptions about what a=
> compiler will do.<br>&gt; <br>&gt; &gt;<br>&gt; &gt; What are the types of=
> p1, p2, etc.?<br>
>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;   - Jay<br>&gt; <br></div></div></div> =
>		 	   		  </div></div>
></blockquote></div><br></div>
>
>--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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
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: <COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/de25268a/attachment-0001.html>

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>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
Message-ID: <F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/8eefc33b/attachment-0001.html>

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: <E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/f5c3a95f/attachment-0001.html>

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: <F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
Message-ID: <E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/bf7e46d6/attachment-0001.html>

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>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
Message-ID: <B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/16d1bf17/attachment-0001.html>

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: <COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/893ed250/attachment-0001.html>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<20130424030938.GA32407@topoi.pooq.com>
Message-ID: <CBBD126A-E22D-446F-A7DF-22C57891BB0B@darko.org>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>

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: <B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
Message-ID: <D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/54cbf25c/attachment-0001.html>

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: <D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
Message-ID: <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com>

On Thu, 25 Apr 2013 07:38:46 +0200
Dragi?a Duri? <dragisha at m3w.org> 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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/975dfc96/attachment-0001.html>

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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@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? <dragisha at m3w.org> 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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
	<20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com>
	<743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org>
	<20130425092740.55bf536a.wagner@elego.de>
Message-ID: <BA56767B-989B-4AC6-9282-B0719E575058@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/eb5a4e3d/attachment-0001.html>

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: <EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>

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" <hendrik at topoi.pooq.com>
Sent: Thursday, April 25, 2013 8:13 PM
To: <m3devel at elegosoft.com>
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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
References: <20130425181303.GA31005@topoi.pooq.com>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/56eab511/attachment-0001.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org>
Message-ID: <DUB123-DS139DB721A365212A6D9327DDB70@phx.gbl>

>> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/3559ed62/attachment-0001.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/148fbf07/attachment-0001.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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? <dragisha at m3w.org> 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: <CC205D88-7E0E-40F3-BAB4-656661B24497@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130428/2dcc99ac/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130428/2dcc99ac/attachment-0001.sig>

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: <E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.com>

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" <rodney at elego.de> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/b8f35830/attachment-0001.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/b8f35830/attachment-0001.sig>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/d033aec3/attachment-0001.html>

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 <hosking at cs.purdue.edu>
> Date: 30 April 2013 5:21:50 PM AEST
> To: Dragi?a Duri? <dragisha at m3w.org>
> Cc: m3devel developers <m3devel at elegosoft.com>
> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/e9e7769a/attachment-0001.html>

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: <E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.com>
References: <20130428190606.3DF769BA007@birch.elegosoft.com>
	<E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.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" <rodney at elego.de> 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 <darko at darko.org> escribi?:

De: Darko <darko at darko.org>
Asunto: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/237cc323/attachment-0002.html>

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. <dabenavidesd at yahoo.es> escribi?:

De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>, "Darko" <darko at darko.org>
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 <darko at darko.org> escribi?:

De: Darko <darko at darko.org>
Asunto: [M3devel] Why do we need external debugging?
Para: "m3devel developers" <m3devel at elegosoft.com>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/5d41fe58/attachment-0002.html>

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: <COL002-W9207521A95605B20119568E6DF0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/eeec11f3/attachment-0002.html>

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: <COL002-W9207521A95605B20119568E6DF0@phx.gbl>
References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org>
	<COL002-W9207521A95605B20119568E6DF0@phx.gbl>
Message-ID: <B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130401/65e234fc/attachment-0002.html>

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: <COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/d6a6f318/attachment-0002.html>

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>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>,
	<3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org>
Message-ID: <COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>

 > 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/39d786b9/attachment-0002.html>

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: <COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130402/00df58d6/attachment-0002.html>

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: <COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>
References: <6E432D64-73BB-4529-9A82-6A63150E5881@darko.org>
	<COL002-W494D78883C2D32226A2284E6DF0@phx.gbl>
	<3A5DF677-C72D-4279-9BD5-9EAB7960AE86@darko.org>
	<COL002-W37355E120BEE0490120C5AE6D80@phx.gbl>
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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/ea047637/attachment-0002.html>

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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>
References: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/fc009799/attachment-0002.html>

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: <B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@darko.org>
References: <1F9A3152-5BD1-4F8A-B651-890A24457D6A@darko.org>
	<COL002-W9207521A95605B20119568E6DF0@phx.gbl>
	<B4291EB8-7237-423C-ABE1-1EC6CA6E7A5B@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
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-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.<div><br></div><div><br><div><div>On Apr 1, 2013, at 9:22 PM, Jay K =
>wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
>type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
>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; "><div =
>class=3D"hmmessage" style=3D"font-size: 12pt; font-family: Calibri; =
>"><div dir=3D"ltr">External debuggers are good. Have you used Visual =
>Studio much?<br>Generate the right debug information and we get =
>excellent working debuggers that people put a lot of time and work =
>into.<br><br><br>On the other hand, I do understand your notion of =
>"internal debugger" and agree it is a good approach.<br><br><br>&nbsp;- =
>Jay<br><br><br><br><div><div id=3D"SkyDrivePlaceholder"></div>&gt; =
>From:<span class=3D"Apple-converted-space">&nbsp;</span><a =
>href=3D"mailto:darko at darko.org">darko at darko.org</a><br>&gt; Date: Mon, 1 =
>Apr 2013 14:53:37 -0700<br>&gt; To:<span =
>class=3D"Apple-converted-space">&nbsp;</span><a =
>href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com</a><br>&gt; =
>Subject: [M3devel] Why do we need external debugging?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; 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?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; 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.<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; Am I the only one =
>who thinks this?<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br>&gt; - =
>Darko<br>&gt;<span =
>class=3D"Apple-converted-space">&nbsp;</span><br></div></div></div></span>=
></blockquote></div><br></div></body></html>=
>
>--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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/d8154f1a/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/d8154f1a/attachment-0002.sig>

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: <COL002-W4639EEA900B0A61A6D4628E6D80@phx.gbl>,
	<3CCA672A-5872-4697-8465-0E10DD2D72E0@m3w.org>
Message-ID: <COL002-W630592CD92EA402C15F4EFE6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/be9866da/attachment-0002.html>

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: <COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/17eb5aef/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: utf8.c
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/17eb5aef/attachment-0002.c>

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: <COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>
References: <3EEBC0CA-37D5-4CFA-B9A6-B21730B999A2@m3w.org>
	<COL002-W56B8CBAF19682C21A6FA34E6D80@phx.gbl>
Message-ID: <C7350F98-1506-4D27-A17C-D78780F493A8@m3w.org>

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
> 
> 
> 
> <utf8.c>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130404/a76eafe6/attachment-0002.html>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/f97d8648/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/f97d8648/attachment-0002.sig>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
References: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
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
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-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?<div><br></div><div><div>new source -&gt; =
>compiling XLModule.m3</div><div>"../src/XLModule.m3", line 181: NARROW: =
>types must be assignable</div><div>"../src/XLModule.m3", line 239: =
>incompatible types (x)</div></div><div><br></div><div>Second one is =
>RefSeq.T.addhi(procedureType)</div><div><br></div><div>TIA,</div><div>dd</=
>div><div><div apple-content-edited=3D"true">
><span class=3D"Apple-style-span" style=3D"font-family: Helvetica; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; =
>"><div>--</div></div></span></div></span><span class=3D"Apple-style-span" =
>style=3D"font-family: Helvetica; ">Dragi=C5=A1a Duri=C4=87</span><span =
>class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=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; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><div><a =
>href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org</a></div><div><br></div>=
></div></span></div></span><br class=3D"Apple-interchange-newline">
></div>
><br></div></body></html>=
>
>--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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/ff1f8a5d/attachment-0002.html>

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: <COL125-W460B9D1DBA8F4A20F9C4C6E6DB0@phx.gbl>


> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130406/7e18ad32/attachment-0002.html>

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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/faa63519/attachment-0002.html>

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: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/090bb91a/attachment-0002.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/03bb17fa/attachment-0002.html>

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: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>
References: <COL125-W32F2C1A0B0A6B4A530E44DE6C40@phx.gbl>
Message-ID: <DE057DD1-657A-4416-BFFC-CBCDBD37481E@cs.purdue.edu>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/d6f89982/attachment-0002.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
	<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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/3f072b33/attachment-0002.html>

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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
References: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
References: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
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 <mailto: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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/217cef9b/attachment-0002.html>

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: <DA444DAE-A454-4B5D-B297-DAEA01C54056@m3w.org>
	<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 <mailto: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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>
	<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: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>,
	<51619569.4070202@lcwb.coop>
Message-ID: <COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/1a8951d1/attachment-0002.html>

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: <COL125-W100E27C14A013B74E041CBE6C40@phx.gbl>,
	<516198AB.5040509@lcwb.coop>,
	<20130407183746.GB24973@topoi.pooq.com>
Message-ID: <COL125-W43C2A24CADBFC0D73FCB2BE6C40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130407/12ca60bb/attachment-0002.html>

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: <COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>,
	<51619569.4070202@lcwb.coop>
	<COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
Message-ID: <DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/3914a798/attachment-0002.html>

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: <DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>
References: <COL125-W38AC2AEDBA1B6A2E75B63DE6DB0@phx.gbl>
	<51619569.4070202@lcwb.coop>
	<COL125-W48887C9A867BF9A11D0820E6C40@phx.gbl>
	<DUB123-DS797173ED0B64969868C61DDC50@phx.gbl>
Message-ID: <D10AB51D-53EC-476D-81D4-62E23A91118E@gmail.com>

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 <dmuysers at hotmail.com> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/af1d20cd/attachment-0002.html>

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: <COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/a7ae8127/attachment-0002.html>

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: <COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>
References: <20130408183918.555525DEA9D@birch.elegosoft.com>
	<COL125-W41F6E7C01A8581E9EF7E79E6C50@phx.gbl>
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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/48f717cd/attachment-0002.html>

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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>
References: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/7119ff90/attachment-0002.html>

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: <COL125-W3378C77A2530BFF2828E8FE6C70@phx.gbl>,
	<42270643-1D09-459E-B8B9-FF2B9E4C671A@cs.purdue.edu>
Message-ID: <COL125-W3209FFD59FB5FA139464F5E6C70@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/15ebe9ef/attachment-0002.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>

  
  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 <stdio.h> 
 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/1d4aae2c/attachment-0002.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>
References: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>
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 <jay.krell at cornell.edu> 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 <stdio.h> 
>  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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/4802481d/attachment-0002.html>

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: <COL125-W24F499CDDA91141F94DDBAE6C00@phx.gbl>,
	<06631461-15B3-4820-BE76-D780EA50685E@cs.purdue.edu>
Message-ID: <COL125-W44460FD17490ADE9571C27E6C00@phx.gbl>

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 <jay.krell at cornell.edu> 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 <stdio.h> 
 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/94639418/attachment-0002.html>

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: <COL125-W25430683673CC692BCD91DE6C00@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/9d59ee77/attachment-0002.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>

 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/f2e41dce/attachment-0002.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/37fa075e/attachment-0002.html>

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: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>,
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>
Message-ID: <COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130411/61ceec09/attachment-0002.html>

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" <rodney_bates at lcwb.coop> 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: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/326d259d/attachment-0002.html>

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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/68e4af1a/attachment-0002.html>

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: <COL125-W2220B0DBBD27BC751336B2E6C10@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130412/1c497771/attachment-0002.html>

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" <rodney_bates at lcwb.coop> 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: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>
References: <COL125-W38D02DED3BCF4240C511D9E6C10@phx.gbl>
Message-ID: <COL125-W419A0D69A6F503301FD15AE6C20@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/70931956/attachment-0002.html>

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: <COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>, ,
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>,
	<COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
Message-ID: <COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>

  >  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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/40f61c0a/attachment-0002.html>

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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
Message-ID: <B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130413/7ab70a40/attachment-0002.html>

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" <rodney_bates at lcwb.coop> wrote:

> On 04/12/2013 01:30 AM, Olaf Wagner wrote:
> > On Thu, 11 Apr 2013 19:48:11 -0500
> > "Rodney M. Bates" <rodney_bates at lcwb.coop> 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: <COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>
References: <COL125-W33D5D03B2C2F18B10C9A9EE6C00@phx.gbl>
	<42696B74-0D3E-4CDA-9BA9-D08B1A44D31B@cs.purdue.edu>
	<COL125-W7E1A7A13E2C49FA48499AE6C00@phx.gbl>
	<COL125-W32A2C8A0A617BF48E375DE6C20@phx.gbl>
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: <B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
	<B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
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: <COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
References: <516825ED.9010003@lcwb.coop>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
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>
	<COL125-W21001F1EEA453F67D14B77E6C10@phx.gbl>
	<B615CD1E-B4EF-478A-88B0-5F672676529A@m3w.org>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/ad6a9379/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/0155dced/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130415/0155dced/attachment-0002.sig>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/ff950909/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/41740f65/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/41740f65/attachment-0002.sig>

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<mailto:dragisha at m3w.org>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/9710fd58/attachment-0002.html>

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: <COL125-W297E6079717EA93196445AE6CD0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/c1fbdc08/attachment-0002.html>

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: <C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/3e77aa77/attachment-0002.html>

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: <COL125-W297E6079717EA93196445AE6CD0@phx.gbl>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL>
	<COL125-W297E6079717EA93196445AE6CD0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/30c58251/attachment-0002.html>

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: <C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF0C284D3A@ATLEX04-SRV.SCIRES.LOCAL>
	<C79EC11B-273B-4DCA-9886-3B60154B042D@m3w.org>
Message-ID: <F39F129F-63BF-4D97-A38B-D140223CA65D@m3w.org>


--
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/d57eb744/attachment-0002.html>

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: <CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>

On Wed, Feb 6, 2013 at 4:38 PM, Olaf Wagner <wagner at elegosoft.com> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/cd30ec59/attachment-0002.html>

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: <CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>
References: <0BB8FA59C2932741A3A2941A8B9D8BFF045FD4@ATLEX04-SRV.SCIRES.LOCAL><00ECCCAC-571A-4678-870D-95444BD49DB0@cs.purdue.edu><51126B00.7010301@columbus.rr.com><20130206163822.f9e2ce778941fc14bdaaccdd@elegosoft.com>
	<CAMPJxLTRQOFEcyXikfPVrpr5a9Zv3iACF0Fadnt6UfKXetPnog@mail.gmail.com>
Message-ID: <DUB123-DS147CC46CF745D3765092DCDDCD0@phx.gbl>

...at least for Linux and FreeBSD,...

and for Windows nobody cares even a bit!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130416/66576caf/attachment-0002.html>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
Message-ID: <COL125-W26FFB529DF12F6F2D8BDA8E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/1c9ead92/attachment-0002.html>

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: <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>
Message-ID: <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/4f243eb7/attachment-0002.html>

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: <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>, ,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>,
	<COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>
Message-ID: <COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/bd4ba51a/attachment-0002.html>

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: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/92fcfe7a/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/92fcfe7a/attachment-0002.sig>

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: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
References: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
Message-ID: <COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/e0afd277/attachment-0002.html>

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: <COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,
	, , <COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>, ,
	<COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>,
	<COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>
Message-ID: <COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/756c6832/attachment-0002.html>

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: <COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>
References: <BDAF3AD2-01F9-4455-972F-38B194589D5D@m3w.org>
	<COL125-W1A8B3D1A048FD24928BE7E6CE0@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/6c783ea2/attachment-0002.html>

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<mailto:dragisha at m3w.org>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130417/558c9408/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130418/58488436/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130418/58488436/attachment-0002.sig>

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: <COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>
References: <20130416012125.2CB685DEB25@birch.elegosoft.com>,,, ,
	<COL125-W21AE783FFB30DF8413D9ECE6CD0@phx.gbl>,
	, , <COL125-W28770FDE311BF295C267D9E6CE0@phx.gbl>, ,
	<COL125-W218A78BB7ECBCA96836EB4E6CE0@phx.gbl>,
	<COL125-W1E6E7B515AA54D38D9789E6CE0@phx.gbl>
Message-ID: <COL125-W45AED01E47C2A01D881B1AE6C80@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130419/a09492f0/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/dc2f2e58/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/dc2f2e58/attachment-0002.sig>

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: <B82932CC-EEEA-48F7-B73F-E80A3D451262@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/b0f0b8ec/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/b0f0b8ec/attachment-0002.sig>

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: <B88E1F85-C3CA-4984-98A9-FBE2260DF392@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/cccd7c70/attachment-0002.html>

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: <COL125-W34743F971FA87AB3E6743DE6C90@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/4c73c99d/attachment-0002.html>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130420/a790221a/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/651a4e41/attachment-0002.html>

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: <CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/4a89abcd/attachment-0002.html>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/006e61ff/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/006e61ff/attachment-0002.sig>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/2cb0db38/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/2cb0db38/attachment-0002.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/4190d521/attachment-0002.html>

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: <COL125-W5EEA2B8A1431DC17C2BDFE6CA0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130421/3ae238bc/attachment-0002.html>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
Message-ID: <20130421234903.fbc4837a0cba1f1c28ebc2d7@elegosoft.com>

On Sun, 21 Apr 2013 20:55:43 +0000
Jay K <jay.krell at cornell.edu> 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: <F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/0553c792/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/0553c792/attachment-0002.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
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: <CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
References: <68D10959-164F-4318-941E-1BF75DFB8B75@m3w.org>
	<20130420211119.bb6dbc3ba14c4aa9b6a4d2f6@elegosoft.com>
	<1B04BEA0-9A7B-4D78-AEB4-C63C770F5723@m3w.org>
	<CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
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 <peter.mckinna at gmail.com> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/58ce8168/attachment-0002.html>

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>
	<CAEy6uxos0GBxKg1R2WR-0kNY=1XgFfZ7htAWFU409KvycxcsDQ@mail.gmail.com>
	<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 <peter.mckinna at gmail.com> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/b4c45f85/attachment-0002.html>

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: <F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/26740f5a/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/26740f5a/attachment-0002.sig>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
Message-ID: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/dbc9b338/attachment-0002.html>

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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
Message-ID: <F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/7302e3f8/attachment-0002.html>

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: <F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<F3F516D4-FA68-4798-8AE4-9EA0BAFCB2B1@darko.org>
Message-ID: <FDCEB4B7-6493-40E5-8723-2CCA445B3DCE@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/015164c4/attachment-0002.html>

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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
Message-ID: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>

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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130422/c5ff907b/attachment-0002.html>

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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
Message-ID: <COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>

 > 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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/b5073b54/attachment-0002.html>

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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
Message-ID: <C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/45562b21/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/45562b21/attachment-0002.sig>

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: <C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
Message-ID: <COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130423/6747d2aa/attachment-0002.html>

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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
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 <jay.krell at cornell.edu> 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
>
><div dir=3D"ltr">There&#39;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&#39;s =
>sometimes called the &quot;absurd&quot; type).</div>
><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Apr 2=
>2, 2013 at 10:38 AM, Jay K <span dir=3D"ltr">&lt;<a href=3D"mailto:jay.krel=
>l at cornell.edu" target=3D"_blank">jay.krell at cornell.edu</a>&gt;</span> wrote=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
>ft:1px #ccc solid;padding-left:1ex">
>
>
>
><div><div dir=3D"ltr">Disclosure: I knew they are of type &quot;NULL&quot;,=
> but I didn&#39;t/don&#39;t know what that type is, or have a mental model =
>for it.<br>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&quot;ADDRESS&quot; presumably. Checks that it is NI=
>L, that is the frontend&#39;s job. The error is just that I check that I kn=
>ow about every type. Some types are &quot;predeclared&quot;, some come from=
> the frontend. I&#39;ll predeclare this. Arguably nothing should be predecl=
>ared.<br>
>=A0<br>=A0<br>=A0=A0- Jay<br>=A0<br><div><div></div>&gt; Date: Sun, 21 Apr =
>2013 21:03:02 -0500<br>&gt; From: <a href=3D"mailto:rodney_bates at lcwb.coop"=
> target=3D"_blank">rodney_bates at lcwb.coop</a><br>&gt; To: <a href=3D"mailto=
>:m3devel at elegosoft.com" target=3D"_blank">m3devel at elegosoft.com</a><br>
>&gt; Subject: Re: [M3devel] null type?<div><div class=3D"h5"><br>&gt; <br>&=
>gt; <br>&gt; <br>&gt; On 04/21/2013 03:55 PM, Jay K wrote:<br>&gt; &gt; Wha=
>t is the meaning of this:<br>&gt; &gt;<br>&gt; &gt; cm3/elego/graphicutils/=
>src/RsrcFilter<br>
>&gt; &gt;<br>&gt; &gt;      init(p1, p2, p3, p4, p5, p6 :=3D NIL) : T;<br>&=
>gt; &gt;      (* Initializes the resource search path. *)<br>&gt; &gt;<br>&=
>gt; &gt;<br>&gt; &gt; PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 :=3D =
>NIL) : T =3D<br>
>&gt; &gt;<br>&gt; <br>&gt; Modula-3 says:<br>&gt; <br>&gt; 2.2.7: &#39;The =
>following reference types are predeclared:<br>&gt;          ...<br>&gt;    =
>      NULL   Contains only NIL&#39;<br>&gt; <br>&gt; And:<br>&gt; <br>&gt; =
>2.2.8: &#39;A formal parameter declaration has the form<br>
>&gt;            Mode Name: Type :=3D Default<br>&gt;          ...<br>&gt;  =
>        If Type is omitted, it is taken to be the type of Default.&#39;<br>=
>&gt; <br>&gt; And:<br>&gt; <br>&gt; 2.6.6: &#39;The literal &quot;NIL&quot;=
> denotes the value NIL.  Its type is NULL.&#39;<br>
>&gt; <br>&gt; So all the pi&#39;s have type NULL, and only NIL can be passe=
>d to them<br>&gt; as actuals.   That&#39;s what the language says.  It look=
>s like the code<br>&gt; in Init thinks it can get non-NIL reference values,=
> but an attempt to pass<br>
>&gt; one in a call should fail a runtime assignability check, since it<br>&=
>gt; won&#39;t be a member of NULL.<br>&gt; <br>&gt; When Init passes one of=
> these to Convert (Yes, I peeked into<br>&gt; RsrcFilter.m3), it is assigna=
>ble, with no runtime check.  Convert<br>
>&gt; thinks it has a REFANY, and other calls to Convert could indeed<br>&gt=
>; give it something non-NIL, but not from the calls in Init.<br>&gt; <br>&g=
>t; Of course, unsafe code could probably LOOPHOLE (remember, any word<br>
>&gt; can be verbed) something non-NIL to NULL and pass it to init/Init.<br>=
>&gt; If the compiler did the most obvious thing, this might do what was<br>=
>&gt; apparently intended.<br>&gt; <br>&gt; But then again, a compiler would=
> be fully compliant with the language<br>
>&gt; and perfectly within its rights to optimize out such a parameter,<br>&=
>gt; not actually pass it at runtime at all, and just insert constant NIL<br=
>>&gt; wherever the formal was referenced in the body of Init, thus undermin=
>ing<br>
>&gt; the above intent.<br>&gt; <br>&gt; Which makes for a good example of h=
>ow unsafe code (almost?) always<br>&gt; depends on assumptions about what a=
> compiler will do.<br>&gt; <br>&gt; &gt;<br>&gt; &gt; What are the types of=
> p1, p2, etc.?<br>
>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;   - Jay<br>&gt; <br></div></div></div> =
>		 	   		  </div></div>
></blockquote></div><br></div>
>
>--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: <CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
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: <COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/de25268a/attachment-0002.html>

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>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
Message-ID: <F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/8eefc33b/attachment-0002.html>

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: <E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/f5c3a95f/attachment-0002.html>

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: <F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
Message-ID: <E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/bf7e46d6/attachment-0002.html>

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>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
Message-ID: <B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/16d1bf17/attachment-0002.html>

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: <COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
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 <jay.krell at cornell.edu> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130424/893ed250/attachment-0002.html>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<20130424030938.GA32407@topoi.pooq.com>
Message-ID: <CBBD126A-E22D-446F-A7DF-22C57891BB0B@darko.org>

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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>,
	<51749A56.4070909@lcwb.coop>,
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>,
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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: <EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>

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: <B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>,
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>,
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>,
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
Message-ID: <D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/54cbf25c/attachment-0002.html>

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: <D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
References: <1A7544A8-6D58-4E43-8A23-454AADD81C77@m3w.org>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
Message-ID: <20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com>

On Thu, 25 Apr 2013 07:38:46 +0200
Dragi?a Duri? <dragisha at m3w.org> 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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/975dfc96/attachment-0002.html>

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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@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? <dragisha at m3w.org> 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>
	<F571B603-B4F6-49B2-85C5-076E8DD057F1@m3w.org>
	<2F5CCB07-1AA4-4B9D-A1BB-B19B67AF9A36@m3w.org>
	<C43010AB-4A44-4123-8DED-7064027F690F@m3w.org>
	<COL125-W31D7D4EC7B45AB7B016620E6B40@phx.gbl>
	<60364381-A65A-4696-AA20-30C7C0F4D9BE@m3w.org>
	<F26AAF18-BCB3-4113-A677-7E440CCBE750@m3w.org>
	<E401D2A2-A94D-45C5-9F0F-34731297AA84@darko.org>
	<234B341B-3829-4627-8F4F-540D54D6B915@m3w.org>
	<B39247C9-8492-4360-8C99-3B4FDB62A885@darko.org>
	<D2BE2AFC-21C8-4FCC-B465-787AC986F10C@m3w.org>
	<20130425083413.90e26e553129fa8b5dd37dca@elegosoft.com>
	<743DE8DC-4E5B-4E6C-A5D7-B573C2DC0B1C@m3w.org>
	<20130425092740.55bf536a.wagner@elego.de>
Message-ID: <BA56767B-989B-4AC6-9282-B0719E575058@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130425/eb5a4e3d/attachment-0002.html>

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: <EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
References: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <COL125-W23D7CA186DE3CF4E443A45E6CA0@phx.gbl>
	<51749A56.4070909@lcwb.coop>
	<COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>

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" <hendrik at topoi.pooq.com>
Sent: Thursday, April 25, 2013 8:13 PM
To: <m3devel at elegosoft.com>
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: <COL125-W1772CF390B4715775A7592E6CB0@phx.gbl>
	<CAM3tuSFmkWz7jTQxy2VV8Zc_iBbENgPAm=W-Pf3u_FF5ak6SCQ@mail.gmail.com>
	<COL125-W1740A05B6C15F6B5769B36E6B40@phx.gbl>
	<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>
	<EEC9F5E6-C282-497D-B534-8C4F608332A8@darko.org>
	<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: <DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
References: <20130425181303.GA31005@topoi.pooq.com>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/56eab511/attachment-0002.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<3F96DBF1-8FAF-4871-8EB5-C626422705BA@m3w.org>
Message-ID: <DUB123-DS139DB721A365212A6D9327DDB70@phx.gbl>

>> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/3559ed62/attachment-0002.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130426/148fbf07/attachment-0002.html>

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>
	<DUB123-DS61FDB74D24BAEF0D1F936DDB60@phx.gbl>
	<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? <dragisha at m3w.org> 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: <CC205D88-7E0E-40F3-BAB4-656661B24497@m3w.org>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130428/2dcc99ac/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130428/2dcc99ac/attachment-0002.sig>

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: <E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.com>

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" <rodney at elego.de> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/b8f35830/attachment-0002.html>
-------------- 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/b8f35830/attachment-0002.sig>

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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/d033aec3/attachment-0002.html>

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 <hosking at cs.purdue.edu>
> Date: 30 April 2013 5:21:50 PM AEST
> To: Dragi?a Duri? <dragisha at m3w.org>
> Cc: m3devel developers <m3devel at elegosoft.com>
> 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? <dragisha at m3w.org> 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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130430/e9e7769a/attachment-0002.html>

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: <E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.com>
References: <20130428190606.3DF769BA007@birch.elegosoft.com>
	<E8ABED01-DB42-4E88-B968-652D0DFB9DC3@gmail.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" <rodney at elego.de> 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.
>>
>