• BCS (11/11) Jul 12 2006 This is a code generator that facilitates the use of an interface across...
• pragma (14/25) Jul 13 2006 Ahh.. so *that's* what you were working on. ;)
• BCS (11/30) Jul 13 2006 done
• BCS (12/20) Jul 18 2006 new version, download:
• BCS (2/2) Aug 01 2006 version next (v0.0.12)

BCS <BCS pathlink.com> writes:

This is a code generator that facilitates the use of an interface across 
a TCP/IP connection

This program takes a limited form of the D programming language 
interface syntax and generates code for an object implementing the 
interface. This Object allows for an instance of the interface to be 
accessed across a TCP/IP connection.

The included readme has a more verbose explanation. Also the package has 
a larger example.

download:
	www.uidaho.edu/~shro8822/netidl_0_6_sdk.zip

Comments and suggestions welcome.

pragma <pragma_member pathlink.com> writes:

In article <e93fnu$1nkb$1 digitaldaemon.com>, BCS says...
This is a code generator that facilitates the use of an interface across 
a TCP/IP connection

This program takes a limited form of the D programming language 
interface syntax and generates code for an object implementing the 
interface. This Object allows for an instance of the interface to be 
accessed across a TCP/IP connection.

The included readme has a more verbose explanation. Also the package has 
a larger example.

download:
	www.uidaho.edu/~shro8822/netidl_0_6_sdk.zip

Comments and suggestions welcome.

Ahh.. so *that's* what you were working on. ;)

I have one suggestion: In your grammar, the BaceType type production could be
streamlined to use your enum values directly:

BaceType = Types.type val
::= "bool"  Type.types.type_bool:val |
"byte"  Type.types.type_void:val | 
"short"  Type.types.type_short:val |
"int"  Type.types.type_int:val |

Granted, its a tradeoff between .bnf readability and code efficency. Clever use
of an alias or two might make this easier on the eyes, but I digress.

Anyway, this technique should help eliminate the need to re-lookup the values in
your backend code.

- EricAnderton at yahoo

BCS <BCS pathlink.com> writes:

pragma wrote:
 
 
 Ahh.. so *that's* what you were working on. ;)
 

yup <g>

 I have one suggestion: In your grammar, the BaceType type production could be
 streamlined to use your enum values directly:
 
 BaceType = Types.type val
 ::= "bool"  Type.types.type_bool:val |
 "byte"  Type.types.type_void:val | 
 "short"  Type.types.type_short:val |
 "int"  Type.types.type_int:val |
 
 Granted, its a tradeoff between .bnf readability and code efficency. Clever use
 of an alias or two might make this easier on the eyes, but I digress.
 
 Anyway, this technique should help eliminate the need to re-lookup the values
in
 your backend code.
 

done
	www.uidaho.edu/~shro8822/netidl_0_7_sdk.zip

also a few tweaks-n-bug-fixes:

--ubyte actually works now
--non-implicit in allowed

I plan to put up a server based on this soon (I have a port promised to 
me). I don't know what it will do, but it will serve as a proof of 
concept. I was thinking of somthing like an entropy source.

"Randome data!!! Randome data!!! Get it while it's fresh!!!" :-P

BCS <BCS pathlink.com> writes:

BCS wrote:
 This is a code generator that facilitates the use of an interface across 
 a TCP/IP connection
 

[...]
 
 The included readme has a more verbose explanation. Also the package has 
 a larger example.
 

 Comments and suggestions welcome.

new version, download:
www.uidaho.edu/~shro8822/netidl_0_11_sdk.zip

a few bug fixes and a new features or two:
--specified Exceptions can now be transported, including
	type and state information.
--Some refactoring of program code
--Some refactoring of generated code
--Fixed bug in .bnf file (warning Enki 1.1 will generate
	illegal code with this .bnf file, add a "{}" at
	the error line)

BCS <BCS pathlink.com> writes:

version next (v0.0.12)

http://www.uidaho.edu/~shro8822/netidl_0_12_sdk.zip