[M3devel] "target specific pragmas"?
Mika Nystrom
mika at async.caltech.edu
Tue Feb 12 22:12:45 CET 2008
Your
seeksomething = Ctargetstdio.seeksomething
should work.
Another thing that might work well is to use generics. For instance, have some
interfaces
Win32Types.i3
MacOSTypes.i3
FreeBSDTypes.i3
And then build your other stuff as generics passing in OSTypes...
of course you can't do *everything* with generics, but type variants
you can do.
About preprocessing. It's clear you're going to have variable code.
When you deal with OS things, of course you will. Currently this
variability is expressed in Quake. There's no way of getting away
from a certain amount of variability as long as you're interfacing
with an OS, I think we all know that. But there's a difference
between doing it in Quake and in Modula-3, which is why I used the
expression "foisting preprocessing on innocent users of high-level
Modula-3". As long as you do it in Quake, no one will expect things
like m3tk to work properly all the time. Once you do it in Modula-3
itself, however, you're inviting users to code absolutely normal
modules with preprocessing that really have no need for preprocessing.
You can't really say "here's a part of the language we're using
that you probably shouldn't use." If it's there, you have to expect
programmers to use it. If it's not, if they do weird things in
Quake, or generate code in Python, on the other hand, they themselves
had better know what they are doing.
Mika
Jay writes:
>--_91974b83-e297-4ab9-ba44-e888f600b934_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Mika good point, I know that, forgot, thanks for reminding me.
> One of the interesting things about Modula-3, or rather anything but C an=
>d C++, is easy parsing, easy building of other tools.
>=20
>Just to be clear though, independent of my crazy ideas, such tools can't ju=
>st enumerate a source tree. I guess they should operate over the pkg tree? =
>You know, they can't understand the source tree without understanding m3mak=
>efiles.
>=20
>I started a little experiment here.
>I added m3-libs/m3core/src/C/common/Cstdio.i3.
>This is a file that ought to be nearly identical for all targets. For now I=
> only changed NT386.
>I'm thinking either:
> a) I'm not quite on base and just fork it per-target, as it was
> b) provide a little bit of C code with #ifdefs, like making the SEEK_* c=
>onstants into VARs and using C to initialize them. That's a bit of a downer=
> though, since constants ought to be constants.
> c) factor it somehow as I was alluding, like, well, again I'm not sure M=
>odula-3 has what I'd want here, but at least for types and constants, you c=
>an push the non-portable stuff into Ctargetstdio.i3 and then expose them in=
> Cstdio.i3, forking only Ctargetstdio.i.
>=20
>I'll explain so I can get my question in. :)
>=20
>I understand, say:
>=20
>Ctargetstdio.i3 (* one of these per target, with not much content *)=20
>CONST
> SEEK_CUR =3D ..; (* target specific probably *)=20
> SEEK_SET =3D ..; ditto=20
> SEEK_END =3D ..; ditto =20
>TYPE
> FOO =3D ... ditto =20
>=20
>Cstdio.i3 (* portable *)=20
> CONST
> SEEK_CUR =3D Ctargetstdio.SEEK_CUR;
> SEEK_SET =3D Ctargetstdio.SEEK_SET;
> SEEK_END =3D Ctargetstdio.SEEK_END;
>TYPE
> FOO =3D Ctargetstdio.FOO;
>=20
>FILE =3D UNTRACED REF RECORD END;
>=20
><extern> procedure fopen(a: const_char_star; b: const_char_star): FILE;
>=20
>It is tedious but I believe it works.
>It'd be nice, I think, if every symbol in one interface could be automatica=
>lly aliases/exposed in another.
> At least for this purpose, maybe not for any other. I'm speculating here,=
> so please respond kindly. :)
>The non portable types and constants can be pushed out and then reexposed a=
>s if they were portable and in one place.
>=20
>However, let's say, for argument/question's sake, that some function accept=
>s int on some targets, off_t on another.
>Nevermind for now how you can portably call it.
>=20
>Ctargetstdio.i3 (* one of these for every target, but another question in a=
> sec ... *)
>=20
><extern> PROCEDURE seeksomething(a: off_t); let's say it is int on some pl=
>atforms.
>=20
>Cstdio.i3 (* the portable one *)
>=20
>seeksomething =3D Ctargetstdio.seeksomething; does this work? I should t=
>ry it out, read the docs.
>=20
>But then the next question would be, let's say there's 20 platforms and 5 u=
>se off_t and 15 use int.
>It's unfortunate if I have to repeat the content 20 times when there are on=
>ly two variants.
>You can see this kind of thing where sometimes we include_dir(TARGET), some=
>times include_dir(OS_TYPE).
>OS_TYPE implies less work, nice.
>=20
>Perhaps concatening stuff in arbitrary way with Quake really is the way?
>It seems almost sarcastic, but perhaps not.
>=20
>As long as the pkg store is easily parsed?
>(There's a setting to ship implementation files. I guess that must be left =
>on? I thought it'd be nice to reduce distribution size..)
>=20
>But for that matter --- <IF_TARGET> could be processed by the compiler and =
>result in a file with it already accounted for and ship that. Isn't that ju=
>st as good? EXCEPT that more thought would have to go into the spec, wherea=
>s m3makefile is already a general purpose system that anyone can do anythin=
>g with?
>=20
>??
>=20
> - Jay
>
>
>
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=
>] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From:=
> mika at async.caltech.edu> > > Can you just generate the Modula-3 code you wa=
>nt using a Python> script or COBOL or whatever you like instead of trying t=
>o foist> preprocessing nastiness on innocent users of high-level Modula-3?>=
> > Preprocessing is super nasty. It's not just a question of human> readabi=
>lity. m3tk has to be able to read the code, too. I should> be able to write=
> a program that reads in (using m3tk) an arbitrary> Modula-3 interface and =
>understands it to the point that it can> generate Network Object stubs, int=
>er-language call stubs, etc. The> stubs should ALSO be human- and m3tk-read=
>able after the transformation!> This should work even if the programmer has=
> been very "clever" in> his use of Modula-3 constructs. (Just try getting s=
>omething like> that to work with C or C++... it's hopeless once the preproc=
>essor> gets involved, and possibly before.)> > Also if I may make a little =
>request, if at all possible, please try> not to break binary compatibility =
>with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about =
>calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--=
>_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset=
>=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist=
> that it depends.> >Putting every platform-specific piece of code in its ow=
>n file/directory can=3D> > lead to mass duplication of nearly identical cod=
>e.> >Sometimes an #if here or there goes very far in /improving/ code maint=
>ainab=3D> >ility.> >A lot of #if here there and everywhere of course can ha=
>ve the opposite effe=3D> >ct.> >And I realize if you were to drop support f=
>or a target, it is easier to fin=3D> >d/delete files/directories than #ifs,=
> but I don't think that's a good enoug=3D> >h reason to sway the decision.>=
> >It goes both ways.> >=3D20> >Yes, you could endeavor factor things down s=
>o that everything common is in =3D> >common, and everything not-common is i=
>n platform-specific. But this is inad=3D> >equate I think. The tail is wagg=
>ing the dog unnecessarily I think. If my co=3D> >de very nearly all goes to=
>gether, don't make me separate it. Also sometimes=3D> > a different factori=
>ng is "encouraged" for other reasons, to match someone =3D> >else's factori=
>ng. Look at the C*.i3 files. They actually can be almost all =3D> >be nearl=
>y the same, yet they are hardly shared at all. I realize you could =3D> >al=
>so do a sort of "forwarding", though I'm not sure that Modula-3 offers al=
>=3D> >l the right capabilities for this. Type forwarding, sure. But how abo=
>ut pro=3D> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D3D common\ccom=
>monstdio.i3 fo=3D> >pen? And having to duplicate a line per type/procedure =
>is lame anyway, you =3D> >KIND OF want "module inheritance". However, if yo=
>u allow preprocessing base=3D> >d on target, perhaps the need for that goes=
> away.> >=3D20> >While extern C varargs functions are generally useless in =
>Modula-3, and the=3D> >refore extern __cdecl is fairly rare, it DOES occur =
>when you write little h=3D> >elpers in C, such as for errno.> >=3D20> >A go=
>od /heuristic/ might be to change the default in any directory that has=3D>=
> > no c_source.> >But it is only heuristic.> >=3D20> >Whatever is done here=
>, some allowance should probably be made for multiple =3D> >calling convent=
>ions in the same file.> >Switching the default to the overwhelming majority=
> and then annotating the =3D> >minority is reasonable.> >=3D20> >I still be=
>lieve that silently ignoring calling conventions on all but NT386=3D> > is =
>VERY reasonable, and that no other platform from here on out will ever =3D>=
> >have calling conventions. Esp. not with the same names. When OS/FOO has t=
>he=3D> > FOOAPI calling convention, you can just ignore that one on all but=
> target =3D> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD p=
>ossibly get ug=3D> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();>=
> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >=
>The One True Calling Convention for all others, calling convention ignored.=
>> >=3D20> >I really believe this is highly highly unlikely to occur, and it=
> is not a t=3D> >errible outcome, and this bridge could be crossed in the f=
>ar off future.> >The functions that are usually in need of calling conventi=
>ons are usually o=3D> >nly present on one system.> >Perhaps ODBC is an extr=
>emely rare anomaly and the whole issue is nearly non=3D> >existant.> >That =
>could be also.> >A change just for ODBC is probably not the best, though it=
> is a very small =3D> >safe harmless change (I always say that :) )> >=3D20=
>> >=3D20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.c=
>om> From: hosking at cs.purdue.e=3D> >du> Subject: Re: [M3devel] "target speci=
>fic pragmas"?> Date: Mon, 11 Feb 20=3D> >08 21:08:46 -0500> To: darko at darko=
>.org> > Indeed!> > On Feb 11, 2008, at 8:=3D> >37 PM, Darko wrote:> > > I t=
>hink it's not a good idea. I think all platform=3D> > specific code > > sho=
>uld be in a separate file. I'd also like to see an op=3D> >tion to > > move=
> calling conventions to the makefile rather than in pramas =3D> >to > > avo=
>id having to duplicate interface files just to have a different >=3D> > > c=
>alling convention for a different platform.> >> > - Darko> >> >> > On 1=3D>=
> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this thro=
>ug=3D> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" i=
>s a good=3D> > > >> idea.> >>> >> Something like either the ability to pref=
>ix pragmas wit=3D> >h a target, > >> or an "iftarget" and "ifnottarget" pra=
>gma.> >>> >> Somethi=3D> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* =
>END_IF_TARGET*>> >>> >>> >=3D> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGE=
>T*>> >> It's a small can of worm=3D> >s.> >> Where can they be placed? Only=
> at "global" scope? (ie: toplevel in >=3D> > >> an interface/module).> >>> =
>>> What about IF_OSTYPE?> >> What about expr=3D> >essions?> >> IF_TARGET NT=
>386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=3D> >> etc.> >>> >> I do=
>n't really have enough interest here to work through thi=3D> >s, > >> just =
>sending out the bait...> >>> >> Obviously this was triggered b=3D> >y my ha=
>ppening into the odbc > >> directory and bringing up ignoring WINAPI=3D> > =
>on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> =
>=3D> >This reminds me of an important point here however -- nobody else > >=
>> is g=3D> >oing to make the mistake of ever having multiple calling > >> c=
>onventions. =3D> >Therefore the generality of prefixing WINAPI with > >> NT=
>386: is useless.> =3D> >>> Unless Mac68K support is added.> >>> >> And here=
> is some rationale even.=3D> > The PC and Mac evolved from > >> "small" sys=
>tems, where assembly programmi=3D> >ng was common, more > >> people knew mo=
>re lower level details and playing g=3D> >ames with > >> calling convention=
>s was something anyone could do. Most othe=3D> >r > >> current systems are =
>rooted in C programming. Working in C, calling >=3D> > >> conventions are g=
>enerally in a hidden layer below what anyone > >> thin=3D> >ks about. There=
>fore, the smaller number of capable people > >> working at t=3D> >hat level=
> have the good sense to only have one calling > >> convention. No =3D> >mor=
>e systems will evolve from "small", at least not > >> without having obs=3D=
>> >erved this history. Therefore, there will no > >> longer be multiple cal=
>lin=3D> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Win=
>dows does=3D> > also have __thiscall and __clrcall. __thiscall is > >> only=
> x86>=3D20> >______________________________________________________________=
>___> >Climb to the top of the charts!=3DA0Play the word scramble challenge =
>with sta=3D> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3D3Dst=
>arshuffle_wlmailtextlink_ja=3D> >n=3D> >> >--_8b04f633-e2a4-411d-940a-739ab=
>79b0616_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Content-Transf=
>er-Encoding: quoted-printable> >> ><html>> ><head>> ><style>> >.hmmessage P=
>> >{> >margin:0px;> >padding:0px> >}> >body.hmmessage> >{> >FONT-SIZE: 10pt=
>;> >FONT-FAMILY:Tahoma> >}> ></style>> ></head>> ><body class=3D3D'hmmessag=
>e'>I insist that it depends.<BR>> >Putting every platform-specific piece of=
> code in its own file/directory can=3D> > lead to mass duplication of nearl=
>y identical code.<BR>> >Sometimes an #if here or there goes very far in /im=
>proving/ code maintainab=3D> >ility.<BR>> >A lot of #if here there and ever=
>ywhere of course can have the opposite effe=3D> >ct.<BR>> >And I realize if=
> you were to drop support for a target, it is easier to fin=3D> >d/delete f=
>iles/directories than #ifs, but I don't think that's a good enoug=3D> >h re=
>ason to sway the decision.<BR>> >It goes both ways.<BR>> > <BR>> >Yes,=
> you could endeavor factor things down so that everything common i=3D>=
> >s in common, and everything not-common is in platform-specific. But this =
>is=3D> > inadequate I think. The tail is wagging the dog unnecessarily I th=
>ink. If =3D> >my code very nearly all goes together, don't make me sep=
>arate it. =3D> >;Also sometimes a different factoring is "encouraged" f=
>or other reasons, to=3D> > match someone else's factoring. Look at the C*.i=
>3 files. They actually can=3D> > be almost all be nearly the same, yet they=
> are hardly shared at all. I rea=3D> >lize you could also do a sort of "for=
>warding", though I'm not sure that Mod=3D> >ula-3 offers all the right capa=
>bilities for this. Type forwarding, sure. Bu=3D> >t how about procedure for=
>warding? Like nt386\cstdio.i3 fopen =3D3D common\cco=3D> >mmonstdio.i3 fope=
>n? And having to duplicate a line per type/procedure is la=3D> >me anyway, =
>you KIND OF want "module inheritance". However, if you allow pre=3D> >proce=
>ssing based on target, perhaps the need for that goes away.<BR>> > <BR=
>>> >While extern C varargs functions are generally useless in Modula-3, and=
> the=3D> >refore extern __cdecl is fairly rare, it DOES occur when you writ=
>e little h=3D> >elpers in C, such as for errno.<BR>> > <BR>> >A good /=
>heuristic/ might be to change the default in any directory that has=3D> > n=
>o c_source.<BR>> >But it is only heuristic.<BR>> > <BR>> >Whatever is =
>done here, some allowance should probably be made for multiple =3D> >callin=
>g conventions in the same file.<BR>> >Switching the default to the overwhel=
>ming majority and then annotating the =3D> >minority is reasonable.<BR>> >&=
>nbsp;<BR>> >I still believe that silently ignoring calling conventions on a=
>ll but NT386=3D> > is VERY reasonable, and that no other platform from here=
> on out will ever =3D> >have calling conventions. Esp. not with the same na=
>mes. When OS/FOO has the=3D> > FOOAPI calling convention, you can just igno=
>re that one on all but target =3D> >OS/FOO. Just as all but NT386 ignore WI=
>NAPI. Yes this COULD possibly get ug=3D> >ly something like:<BR>> ><*EXT=
>ERN FOOAPI WINAPI*> fopen();<BR>> >FOOAPI for OS/FOO, WINAPI ignored.<BR=
>>> >WINAPI for NT386, FOOAPI ignored.<BR>> >The One True Calling Convention=
> for all others, calling convention ignored.=3D> ><BR>> > <BR>> >I rea=
>lly believe this is highly highly unlikely to occur, and it is not a t=3D> =
>>errible outcome, and this bridge could be crossed in the far off future.<B=
>R=3D> >>> >The functions that are usually in need of calling conventions ar=
>e usually o=3D> >nly present on one system.<BR>> >Perhaps ODBC is an extrem=
>ely rare anomaly and the whole issue is nearly non=3D> >existant.<BR>> >Tha=
>t could be also.<BR>> >A change just for ODBC is probably not the best, tho=
>ugh it is a very small =3D> >safe harmless change (I always say that :) )<B=
>R>> > <BR>> > <BR>> > - Jay<BR><BR>> >> ><HR id=3D3DstopSpel=
>ling>> ><BR>> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>> =
>From: hosking at c=3D> >s.purdue.edu<BR>> Subject: Re: [M3devel] "target sp=
>ecific pragmas"?<BR>&=3D> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500<BR>>=
>; To: darko at darko.org<BR>&g=3D> >t; <BR>> Indeed!<BR>> <BR>> On Fe=
>b 11, 2008, at 8:37 PM, Darko wro=3D> >te:<BR>> <BR>> > I think it=
>'s not a good idea. I think all platfor=3D> >m specific code <BR>> > =
>should be in a separate file. I'd also like t=3D> >o see an option to <BR>&=
>gt; > move calling conventions to the makefile r=3D> >ather than in pram=
>as to <BR>> > avoid having to duplicate interface f=3D> >iles just to=
> have a different <BR>> > calling convention for a differ=3D> >ent pl=
>atform.<BR>> ><BR>> > - Darko<BR>> ><BR>> ><B=3D> >=
>R>> > On 12/02/2008, at 12:21 PM, Jay wrote:<BR>> ><BR>> >=
>=3D> >;> So I have NOT thought this through.<BR>> >><BR>> &g=
>t;>=3D> > I wonder if "preprocessing" dependent only on "target" is a go=
>od <BR>> =3D> >>> idea.<BR>> >><BR>> >> Somethin=
>g like either the =3D> >ability to prefix pragmas with a target, <BR>> &=
>gt;> or an "iftarget"=3D> > and "ifnottarget" pragma.<BR>> >><B=
>R>> >> Something like=3D> > so:<BR>> >><BR>> >> =
><* IF_TARGET NT386 *><BR>> =3D> >>> <* END_IF_TARGET*>=
><BR>> >><BR>> >><BR>>=3D> > >> <* IF_TARGET N=
>T386 *><BR>> >> <* END_IF_TARGET*=3D> >><BR>> >>=
> It's a small can of worms.<BR>> >> Where can=3D> > they be placed=
>? Only at "global" scope? (ie: toplevel in <BR>> >>=3D> > an inter=
>face/module).<BR>> >><BR>> >> What about IF_OSTY=3D> >PE?=
><BR>> >> What about expressions?<BR>> >> IF_TARGET NT3=3D=
>> >86 OR NTAMD64<BR>> >><BR>> >> IF_TARGET STARTS(NT)<BR>=
>>=3D> >; >><BR>> >> etc.<BR>> >><BR>> >>=
> I don't =3D> >really have enough interest here to work through this, <BR>&=
>gt; >> ju=3D> >st sending out the bait...<BR>> >><BR>> &g=
>t;> Obviously this=3D> > was triggered by my happening into the odbc <BR=
>>> >> directory an=3D> >d bringing up ignoring WINAPI on non-NT386=
> or <BR>> >> prefixing c=3D> >alling conventions with a target.<BR=
>>> >><BR>> >> This re=3D> >minds me of an important point=
> here however -- nobody else <BR>> >>=3D> >; is going to make the m=
>istake of ever having multiple calling <BR>> >=3D> >;> conventions.=
> Therefore the generality of prefixing WINAPI with <BR>&g=3D> >t; >> =
>NT386: is useless.<BR>> >> Unless Mac68K support is ad=3D> >ded.<B=
>R>> >><BR>> >> And here is some rationale even. The=3D> >=
> PC and Mac evolved from <BR>> >> "small" systems, where assembly =
>=3D> >programming was common, more <BR>> >> people knew more lower=
> level=3D> > details and playing games with <BR>> >> calling conve=
>ntions was s=3D> >omething anyone could do. Most other <BR>> >> cu=
>rrent systems are =3D> >rooted in C programming. Working in C, calling <BR>=
>> >> convention=3D> >s are generally in a hidden layer below what =
>anyone <BR>> >> think=3D> >s about. Therefore, the smaller number =
>of capable people <BR>> >> =3D> >working at that level have the go=
>od sense to only have one calling <BR>>=3D> > >> convention. No mo=
>re systems will evolve from "small", at least no=3D> >t <BR>> >> w=
>ithout having observed this history. Therefore, there =3D> >will no <BR>>=
>; >> longer be multiple calling conventions.<BR>> &=3D> >gt;><B=
>R>> >> That is my theory at least.<BR>> >><BR>&g=3D> >t; =
>>> Oh, Windows does also have __thiscall and __clrcall. __thiscall=3D=
>> > is <BR>> >> only x86<BR>> <BR><BR><br /><hr />Climb to the =
>top=3D> > of the charts!=3DA0Play the word scramble challenge with star pow=
>er. <a href=3D> >=3D3D'http://club.live.com/star_shuffle.aspx?icid=3D3Dstar=
>shuffle_wlmailtextlin=3D> >k_jan' target=3D3D'_new'>Play now!</a></body>> >=
></html>=3D> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_--
>_________________________________________________________________
>Climb to the top of the charts!=A0Play the word scramble challenge with sta=
>r power.
>http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=
>n=
>
>--_91974b83-e297-4ab9-ba44-e888f600b934_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px;
>padding:0px
>}
>body.hmmessage
>{
>FONT-SIZE: 10pt;
>FONT-FAMILY:Tahoma
>}
></style>
></head>
><body class=3D'hmmessage'>Mika good point, I know that, forgot, thanks for =
>reminding me.<BR>
> One of the interesting things about Modula-3, or rather anything but=
> C and C++, is easy parsing, easy building of other tools.<BR>
> <BR>
>Just to be clear though, independent of my crazy ideas, such tools can't ju=
>st enumerate a source tree. I <EM>guess</EM> they should operate over the p=
>kg tree? You know, they can't understand the source tree without understand=
>ing m3makefiles.<BR>
> <BR>
>I started a little experiment here.<BR>
>I added m3-libs/m3core/src/C/common/Cstdio.i3.<BR>
>This is a file that ought to be nearly identical for all targets. For now I=
> only changed NT386.<BR>
>I'm thinking either:<BR>
> a) I'm not quite on base and just fork it per-target, as it wa=
>s<BR>
b) provide a little bit of C code with #ifdefs, like making th=
>e SEEK_* constants into VARs and using C to initialize them. That's a bit o=
>f a downer though, since constants ought to be constants.<BR>
> c) factor it somehow as I was alluding, like, well, again I'm =
>not sure Modula-3 has what I'd want here, but at least for types and consta=
>nts, you can push the non-portable stuff into Ctargetstdio.i3 and then expo=
>se them in Cstdio.i3, forking only Ctargetstdio.i.<BR>
> <BR>
>I'll explain so I can get my question in. :)<BR>
> <BR>
>I understand, say:<BR>
> <BR>
>Ctargetstdio.i3 (* one of these per target, with not much content *) <=
>BR>
>CONST<BR>
> SEEK_CUR =3D ..; (* target specific probably *) <BR>
> SEEK_SET =3D ..; ditto <BR>
> SEEK_END =3D ..; ditto <BR>
>TYPE<BR>
> FOO =3D ... ditto <BR>
> <BR>
>Cstdio.i3 (* portable *) <BR>
> CONST<BR>
> SEEK_CUR =3D Ctargetstdio.SEEK_CUR;<BR>
> SEEK_SET =3D Ctargetstdio.SEEK_SET;<BR>
> SEEK_END =3D Ctargetstdio.<FONT face=3D"">SEEK_END</FONT>;<BR>
>TYPE<BR>
> FOO =3D Ctargetstdio.FOO;<BR>
> <BR>
>FILE =3D UNTRACED REF RECORD END;<BR>
> <BR>
><extern> procedure fopen(a: const_char_star; b: const_char_star): FIL=
>E;<BR>
> <BR>
>It is tedious but I believe it works.<BR>
>It'd be nice, I think, if every symbol in one interface could be autom=
>atically aliases/exposed in another.<BR>
> At least for this purpose, maybe not for any other. I'm speculating =
>here, so please respond kindly. :)<BR>
>The non portable types and constants can be pushed out and then reexposed a=
>s if they were portable and in one place.<BR>
> <BR>
>However, let's say, for argument/question's sake, that some function accept=
>s int on some targets, off_t on another.<BR>
>Nevermind for now how you can portably call it.<BR>
> <BR>
>Ctargetstdio.i3 (* one of these for every target, but another question in&n=
>bsp;a sec ... *)<BR>
> <BR>
><extern> PROCEDURE seeksomething(a: off_t); let's say it is int=
> on some platforms.<BR>
> <BR>
>Cstdio.i3 (* the portable one *)<BR>
> <BR>
>seeksomething =3D Ctargetstdio.seeksomething; does this w=
>ork? I should try it out, read the docs.<BR>
> <BR>
>But then the next question would be, let's say there's 20 platforms and 5 u=
>se off_t and 15 use int.<BR>
>It's unfortunate if I have to repeat the content 20 times when there are on=
>ly two variants.<BR>
>You can see this kind of thing where sometimes we include_dir(TARGET), some=
>times include_dir(OS_TYPE).<BR>
>OS_TYPE implies less work, nice.<BR>
> <BR>
>Perhaps concatening stuff in arbitrary way with Quake really is the way?<BR=
>>
>It seems almost sarcastic, but perhaps not.<BR>
> <BR>
>As long as the pkg store is easily parsed?<BR>
>(There's a setting to ship implementation files. I guess that must be left =
>on? I thought it'd be nice to reduce distribution size..)<BR>
> <BR>
>But for that matter --- <IF_TARGET> could be processed by the compile=
>r and result in a file with it already accounted for and ship that. Isn't t=
>hat just as good? EXCEPT that more thought would have to go into the spec, =
>whereas m3makefile is already a general purpose system that anyone can do a=
>nything with?<BR>
> <BR>
>??<BR>
> <BR>
> - Jay<BR><BR>
>
><HR id=3DstopSpelling>
><BR>
>> To: jayk123 at hotmail.com<BR>> CC: m3devel at elegosoft.com<BR>> Subj=
>ect: Re: [M3devel] "target specific pragmas"? <BR>> Date: Tue, 12 Feb 20=
>08 04:56:02 -0800<BR>> From: mika at async.caltech.edu<BR>> <BR>> <BR=
>>> Can you just generate the Modula-3 code you want using a Python<BR>&g=
>t; script or COBOL or whatever you like instead of trying to foist<BR>> =
>preprocessing nastiness on innocent users of high-level Modula-3?<BR>> <=
>BR>> Preprocessing is super nasty. It's not just a question of human<BR>=
>> readability. m3tk has to be able to read the code, too. I should<BR>&g=
>t; be able to write a program that reads in (using m3tk) an arbitrary<BR>&g=
t; Modula-3 interface and understands it to the point that it can<BR>> g=
>enerate Network Object stubs, inter-language call stubs, etc. The<BR>> s=
>tubs should ALSO be human- and m3tk-readable after the transformation!<BR>&=
>gt; This should work even if the programmer has been very "clever" in<BR>&g=
>t; his use of Modula-3 constructs. (Just try getting something like<BR>>=
> that to work with C or C++... it's hopeless once the preprocessor<BR>> =
>gets involved, and possibly before.)<BR>> <BR>> Also if I may make a =
>little request, if at all possible, please try<BR>> not to break binary =
>compatibility with gcc-compiled C and Fortran<BR>> on NT386GNU (not sure=
> if your ideas about calling conventions could<BR>> possibly do that...)=
><BR>> <BR>> Mika<BR>> <BR>> Jay writes:<BR>> >--_8b04f633=
>-e2a4-411d-940a-739ab79b0616_<BR>> >Content-Type: text/plain; charset=
>=3D"iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>=
>> ><BR>> >I insist that it depends.<BR>> >Putting every p=
>latform-specific piece of code in its own file/directory can=3D<BR>> >=
>; lead to mass duplication of nearly identical code.<BR>> >Sometimes =
>an #if here or there goes very far in /improving/ code maintainab=3D<BR>>=
>; >ility.<BR>> >A lot of #if here there and everywhere of course c=
>an have the opposite effe=3D<BR>> >ct.<BR>> >And I realize if y=
>ou were to drop support for a target, it is easier to fin=3D<BR>> >d/=
>delete files/directories than #ifs, but I don't think that's a good enoug=
>=3D<BR>> >h reason to sway the decision.<BR>> >It goes both way=
>s.<BR>> >=3D20<BR>> >Yes, you could endeavor factor things down=
> so that everything common is in =3D<BR>> >common, and everything not=
>-common is in platform-specific. But this is inad=3D<BR>> >equate I t=
>hink. The tail is wagging the dog unnecessarily I think. If my co=3D<BR>>=
>; >de very nearly all goes together, don't make me separate it. Also som=
>etimes=3D<BR>> > a different factoring is "encouraged" for other reas=
>ons, to match someone =3D<BR>> >else's factoring. Look at the C*.i3 f=
>iles. They actually can be almost all =3D<BR>> >be nearly the same, y=
>et they are hardly shared at all. I realize you could =3D<BR>> >also =
>do a sort of "forwarding", though I'm not sure that Modula-3 offers al=3D<B=
>R>> >l the right capabilities for this. Type forwarding, sure. But ho=
>w about pro=3D<BR>> >cedure forwarding? Like nt386\cstdio.i3 fopen =
>=3D3D common\ccommonstdio.i3 fo=3D<BR>> >pen? And having to duplicate=
> a line per type/procedure is lame anyway, you =3D<BR>> >KIND OF want=
> "module inheritance". However, if you allow preprocessing base=3D<BR>> =
>>d on target, perhaps the need for that goes away.<BR>> >=3D20<BR>=
>> >While extern C varargs functions are generally useless in Modula-3=
>, and the=3D<BR>> >refore extern __cdecl is fairly rare, it DOES occu=
>r when you write little h=3D<BR>> >elpers in C, such as for errno.<BR=
>>> >=3D20<BR>> >A good /heuristic/ might be to change the defau=
>lt in any directory that has=3D<BR>> > no c_source.<BR>> >But i=
>t is only heuristic.<BR>> >=3D20<BR>> >Whatever is done here, s=
>ome allowance should probably be made for multiple =3D<BR>> >calling =
>conventions in the same file.<BR>> >Switching the default to the over=
>whelming majority and then annotating the =3D<BR>> >minority is reaso=
>nable.<BR>> >=3D20<BR>> >I still believe that silently ignoring=
> calling conventions on all but NT386=3D<BR>> > is VERY reasonable, a=
>nd that no other platform from here on out will ever =3D<BR>> >have c=
>alling conventions. Esp. not with the same names. When OS/FOO has the=3D<BR=
>>> > FOOAPI calling convention, you can just ignore that one on all b=
>ut target =3D<BR>> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes =
>this COULD possibly get ug=3D<BR>> >ly something like:<BR>> >&l=
>t;*EXTERN FOOAPI WINAPI*> fopen();<BR>> >FOOAPI for OS/FOO, WINAPI=
> ignored.<BR>> >WINAPI for NT386, FOOAPI ignored.<BR>> >The One=
> True Calling Convention for all others, calling convention ignored.<BR>>=
>; >=3D20<BR>> >I really believe this is highly highly unlikely to =
>occur, and it is not a t=3D<BR>> >errible outcome, and this bridge co=
>uld be crossed in the far off future.<BR>> >The functions that are us=
>ually in need of calling conventions are usually o=3D<BR>> >nly prese=
>nt on one system.<BR>> >Perhaps ODBC is an extremely rare anomaly and=
> the whole issue is nearly non=3D<BR>> >existant.<BR>> >That co=
>uld be also.<BR>> >A change just for ODBC is probably not the best, t=
>hough it is a very small =3D<BR>> >safe harmless change (I always say=
> that :) )<BR>> >=3D20<BR>> >=3D20<BR>> > - Jay<BR>> &=
>gt;<BR>> ><BR>> ><BR>> >> CC: jayk123 at hotmail.com; m3d=
>evel at elegosoft.com> From: hosking at cs.purdue.e=3D<BR>> >du> Subj=
>ect: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=3D<B=
>R>> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> &=
>gt; On Feb 11, 2008, at 8:=3D<BR>> >37 PM, Darko wrote:> > >=
> I think it's not a good idea. I think all platform=3D<BR>> > specifi=
>c code > > should be in a separate file. I'd also like to see an op=
>=3D<BR>> >tion to > > move calling conventions to the makefile =
>rather than in pramas =3D<BR>> >to > > avoid having to duplicat=
>e interface files just to have a different >=3D<BR>> > > callin=
>g convention for a different platform.> >> > - Darko> >&g=
>t; >> > On 1=3D<BR>> >2/02/2008, at 12:21 PM, Jay wrote:>=
> >> >> So I have NOT thought this throug=3D<BR>> >h.> =
>>>> >> I wonder if "preprocessing" dependent only on "target=
>" is a good=3D<BR>> > > >> idea.> >>> >> S=
>omething like either the ability to prefix pragmas wit=3D<BR>> >h a t=
>arget, > >> or an "iftarget" and "ifnottarget" pragma.> >>=
>;> >> Somethi=3D<BR>> >ng like so:> >>> >>=
> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >=
>>> >>> >=3D<BR>> >> <* IF_TARGET NT386 *>&=
>gt; >> <* END_IF_TARGET*>> >> It's a small can of worm=
>=3D<BR>> >s.> >> Where can they be placed? Only at "global" =
>scope? (ie: toplevel in >=3D<BR>> > >> an interface/module).=
>> >>> >> What about IF_OSTYPE?> >> What about ex=
>pr=3D<BR>> >essions?> >> IF_TARGET NT386 OR NTAMD64> >=
>>> >> IF_TARGET STARTS(NT)> >>> >=3D<BR>> >=
>;> etc.> >>> >> I don't really have enough interest he=
>re to work through thi=3D<BR>> >s, > >> just sending out the=
> bait...> >>> >> Obviously this was triggered b=3D<BR>>=
>; >y my happening into the odbc > >> directory and bringing up =
>ignoring WINAPI=3D<BR>> > on non-NT386 or > >> prefixing cal=
>ling conventions with a target.> >>> >> =3D<BR>> >T=
>his reminds me of an important point here however -- nobody else > >&=
>gt; is g=3D<BR>> >oing to make the mistake of ever having multiple ca=
>lling > >> conventions. =3D<BR>> >Therefore the generality o=
>f prefixing WINAPI with > >> NT386: is useless.> =3D<BR>> &g=
>t;>> Unless Mac68K support is added.> >>> >> And he=
>re is some rationale even.=3D<BR>> > The PC and Mac evolved from >=
> >> "small" systems, where assembly programmi=3D<BR>> >ng was c=
>ommon, more > >> people knew more lower level details and playing =
>g=3D<BR>> >ames with > >> calling conventions was something =
>anyone could do. Most othe=3D<BR>> >r > >> current systems a=
>re rooted in C programming. Working in C, calling >=3D<BR>> > >=
>> conventions are generally in a hidden layer below what anyone > >=
>;> thin=3D<BR>> >ks about. Therefore, the smaller number of capabl=
>e people > >> working at t=3D<BR>> >hat level have the good =
>sense to only have one calling > >> convention. No =3D<BR>> >=
>;more systems will evolve from "small", at least not > >> without =
>having obs=3D<BR>> >erved this history. Therefore, there will no >=
> >> longer be multiple callin=3D<BR>> >g conventions.> >&=
>gt;> >> That is my theory at least.> >>> >> Oh, =
>Windows does=3D<BR>> > also have __thiscall and __clrcall. __thiscall=
> is > >> only x86>=3D20<BR>> >___________________________=
>______________________________________<BR>> >Climb to the top of the =
>charts!=3DA0Play the word scramble challenge with sta=3D<BR>> >r powe=
>r.<BR>> >http://club.live.com/star_shuffle.aspx?icid=3D3Dstarshuffle_=
>wlmailtextlink_ja=3D<BR>> >n=3D<BR>> ><BR>> >--_8b04f633-=
>e2a4-411d-940a-739ab79b0616_<BR>> >Content-Type: text/html; charset=
>=3D"iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>=
>> ><BR>> ><html><BR>> ><head><BR>> ><=
>;style><BR>> >.hmmessage P<BR>> >{<BR>> >margin:0px;<B=
>R>> >padding:0px<BR>> >}<BR>> >body.hmmessage<BR>> >=
>;{<BR>> >FONT-SIZE: 10pt;<BR>> >FONT-FAMILY:Tahoma<BR>> >=
>}<BR>> ></style><BR>> ></head><BR>> ><body=
> class=3D3D'hmmessage'>I insist that it depends.<BR><BR>> >P=
>utting every platform-specific piece of code in its own file/directory can=
>=3D<BR>> > lead to mass duplication of nearly identical code.<BR&g=
>t;<BR>> >Sometimes an #if here or there goes very far in /improving/ =
>code maintainab=3D<BR>> >ility.<BR><BR>> >A lot of #if he=
>re there and everywhere of course can have the opposite effe=3D<BR>> >=
>;ct.<BR><BR>> >And I realize if you were to drop support for a =
>target, it is easier to fin=3D<BR>> >d/delete files/directories than =
>#ifs, but I don't think that's a good enoug=3D<BR>> >h reason to sway=
> the decision.<BR><BR>> >It goes both ways.<BR><BR>> &=
>gt; <BR><BR>> >Yes, you could endeavor factor=
> things down so that everything common i=3D<BR>> >s in common, and ev=
>erything not-common is in platform-specific. But this is=3D<BR>> > in=
>adequate I think. The tail is wagging the dog unnecessarily I think. If =3D=
><BR>> >my code very nearly all goes together, don't make me =
>separate it. =3D<BR>> >;Also sometimes a different factoring =
>is "encouraged" for other reasons, to=3D<BR>> > match someone else's =
>factoring. Look at the C*.i3 files. They actually can=3D<BR>> > be al=
>most all be nearly the same, yet they are hardly shared at all. I rea=3D<BR=
>>> >lize you could also do a sort of "forwarding", though I'm not sur=
>e that Mod=3D<BR>> >ula-3 offers all the right capabilities for this.=
> Type forwarding, sure. Bu=3D<BR>> >t how about procedure forwarding?=
> Like nt386\cstdio.i3 fopen =3D3D common\cco=3D<BR>> >mmonstdio.i3 fo=
>pen? And having to duplicate a line per type/procedure is la=3D<BR>> >=
>;me anyway, you KIND OF want "module inheritance". However, if you allow pr=
>e=3D<BR>> >processing based on target, perhaps the need for that goes=
> away.<BR><BR>> > <BR><BR>> >While extern =
>C varargs functions are generally useless in Modula-3, and the=3D<BR>> &=
>gt;refore extern __cdecl is fairly rare, it DOES occur when you write littl=
>e h=3D<BR>> >elpers in C, such as for errno.<BR><BR>> >&a=
>mp;nbsp;<BR><BR>> >A good /heuristic/ might be to change the de=
>fault in any directory that has=3D<BR>> > no c_source.<BR><BR>&=
>gt; >But it is only heuristic.<BR><BR>> > <BR>=
>;<BR>> >Whatever is done here, some allowance should probably be made=
> for multiple =3D<BR>> >calling conventions in the same file.<BR&g=
>t;<BR>> >Switching the default to the overwhelming majority and then =
>annotating the =3D<BR>> >minority is reasonable.<BR><BR>> &g=
>t; <BR><BR>> >I still believe that silently ignoring c=
>alling conventions on all but NT386=3D<BR>> > is VERY reasonable, and=
> that no other platform from here on out will ever =3D<BR>> >have cal=
>ling conventions. Esp. not with the same names. When OS/FOO has the=3D<BR>&=
>gt; > FOOAPI calling convention, you can just ignore that one on all but=
> target =3D<BR>> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes th=
is COULD possibly get ug=3D<BR>> >ly something like:<BR><BR>>=
>; ><*EXTERN FOOAPI WINAPI*> fopen();<BR><BR>> >=
>;FOOAPI for OS/FOO, WINAPI ignored.<BR><BR>> >WINAPI for NT386,=
> FOOAPI ignored.<BR><BR>> >The One True Calling Convention for =
>all others, calling convention ignored.=3D<BR>> ><BR><BR>> &=
>gt; <BR><BR>> >I really believe this is highly highly =
>unlikely to occur, and it is not a t=3D<BR>> >errible outcome, and th=
>is bridge could be crossed in the far off future.<BR=3D<BR>> >>=
><BR>> >The functions that are usually in need of calling conventions =
>are usually o=3D<BR>> >nly present on one system.<BR><BR>> &=
>gt;Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly =
>non=3D<BR>> >existant.<BR><BR>> >That could be also.<B=
>R><BR>> >A change just for ODBC is probably not the best, though i=
>t is a very small =3D<BR>> >safe harmless change (I always say that :=
>) )<BR><BR>> > <BR><BR>> > <BR=
>><BR>> > - Jay<BR><BR><BR>> ><BR>> &=
>gt;<HR id=3D3DstopSpelling><BR>> ><BR><BR>> >&g=
>t; CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>> From: h=
>osking at c=3D<BR>> >s.purdue.edu<BR>> Subject: Re: [M3deve=
>l] "target specific pragmas"?<BR>&=3D<BR>> >gt; Date: Mon, =
>11 Feb 2008 21:08:46 -0500<BR>> To: darko at darko.org<BR>&=
>amp;g=3D<BR>> >t; <BR>> Indeed!<BR>> <BR=
>>> On Feb 11, 2008, at 8:37 PM, Darko wro=3D<BR>> >te:<B=
>R>> <BR>> > I think it's not a good idea. I t=
>hink all platfor=3D<BR>> >m specific code <BR>> >=
> should be in a separate file. I'd also like t=3D<BR>> >o see an opti=
>on to <BR>> > move calling conventions to the makefile =
>r=3D<BR>> >ather than in pramas to <BR>> > avoid =
>having to duplicate interface f=3D<BR>> >iles just to have a differen=
>t <BR>> > calling convention for a differ=3D<BR>> &g=
>t;ent platform.<BR>> ><BR>> > - Dar=
>ko<BR>> ><BR>> ><B=3D<BR>> &g=
>t;R>> > On 12/02/2008, at 12:21 PM, Jay wrote:<BR>&a=
>mp;gt; ><BR>> >=3D<BR>> >;> So I hav=
>e NOT thought this through.<BR>> >><BR>&am=
>p;gt; >>=3D<BR>> > I wonder if "preprocessing" dependen=
>t only on "target" is a good <BR>> =3D<BR>> >>&am=
>p;gt; idea.<BR>> >><BR>> >&a=
>mp;gt; Something like either the =3D<BR>> >ability to prefix pragmas =
>with a target, <BR>> >> or an "iftarget"=3D<BR>&=
>gt; > and "ifnottarget" pragma.<BR>> >><BR=
>>> >> Something like=3D<BR>> > so:<BR>&=
>amp;gt; >><BR>> >> <* IF_TA=
>RGET NT386 *><BR>> =3D<BR>> >>> &am=
>p;lt;* END_IF_TARGET*><BR>> >><BR>&=
>amp;gt; >><BR>>=3D<BR>> > >>=
> <* IF_TARGET NT386 *><BR>> >> &am=
>p;lt;* END_IF_TARGET*=3D<BR>> >><BR>> >&am=
>p;gt; It's a small can of worms.<BR>> >> Where c=
>an=3D<BR>> > they be placed? Only at "global" scope? (ie: toplevel in=
> <BR>> >>=3D<BR>> > an interface/module).&=
>lt;BR>> >><BR>> >> What =
>about IF_OSTY=3D<BR>> >PE?<BR>> >> What ab=
>out expressions?<BR>> >> IF_TARGET NT3=3D<BR>>=
>; >86 OR NTAMD64<BR>> >><BR>> &a=
>mp;gt;> IF_TARGET STARTS(NT)<BR>>=3D<BR>> >; &=
>gt;><BR>> >> etc.<BR>> &=
>gt;><BR>> >> I don't =3D<BR>> >real=
>ly have enough interest here to work through this, <BR>> &=
>gt;> ju=3D<BR>> >st sending out the bait...<BR>> =
>>><BR>> >> Obviously this=3D<BR>&g=
>t; > was triggered by my happening into the odbc <BR>> &=
>;gt;> directory an=3D<BR>> >d bringing up ignoring WINAPI on n=
>on-NT386 or <BR>> >> prefixing c=3D<BR>> >=
>alling conventions with a target.<BR>> >><BR&=
>gt;> >> This re=3D<BR>> >minds me of an importan=
>t point here however -- nobody else <BR>> >>=3D<B=
>R>> >; is going to make the mistake of ever having multiple calling &=
>lt;BR>> >=3D<BR>> >;> conventions. Therefore t=
>he generality of prefixing WINAPI with <BR>&g=3D<BR>> >t; &=
>amp;gt;> NT386: is useless.<BR>> >> Unles=
>s Mac68K support is ad=3D<BR>> >ded.<BR>> >&g=
>t;<BR>> >> And here is some rationale even. The=
>=3D<BR>> > PC and Mac evolved from <BR>> >>=
>; "small" systems, where assembly =3D<BR>> >programming was common, m=
>ore <BR>> >> people knew more lower level=3D<BR>=
>> > details and playing games with <BR>> >>=
>; calling conventions was s=3D<BR>> >omething anyone could do. Most o=
>ther <BR>> >> current systems are =3D<BR>> &g=
>t;rooted in C programming. Working in C, calling <BR>> >=
>;> convention=3D<BR>> >s are generally in a hidden layer below=
> what anyone <BR>> >> think=3D<BR>> >s abo=
>ut. Therefore, the smaller number of capable people <BR>> &=
>;gt;> =3D<BR>> >working at that level have the good sense to o=
>nly have one calling <BR>>=3D<BR>> > >> co=
>nvention. No more systems will evolve from "small", at least no=3D<BR>> =
>>t <BR>> >> without having observed this hist=
>ory. Therefore, there =3D<BR>> >will no <BR>> >&a=
>mp;gt; longer be multiple calling conventions.<BR>> &=3D<B=
>R>> >gt;><BR>> >> That is my theory=
> at least.<BR>> >><BR>&g=3D<BR>> &g=
>t;t; >> Oh, Windows does also have __thiscall and __clrcall. =
>__thiscall=3D<BR>> > is <BR>> >> only x86&=
>lt;BR>> <BR><BR><br /><hr />Climb to the =
>top=3D<BR>> > of the charts!=3DA0Play the word scramble challenge wit=
>h star power. <a href=3D<BR>> >=3D3D'http://club.live.com/star_shu=
>ffle.aspx?icid=3D3Dstarshuffle_wlmailtextlin=3D<BR>> >k_jan' target=
>=3D3D'_new'>Play now!</a></body><BR>> ></html>=
>=3D<BR>> ><BR>> >--_8b04f633-e2a4-411d-940a-739ab79b0616_--<BR>=
><BR><br /><hr />Climb to the top of the charts!=A0Play the word scramble ch=
>allenge with star power. <a href=3D'http://club.live.com/star_shuffle.aspx?=
>icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now!</a></body>
></html>=
>
>--_91974b83-e297-4ab9-ba44-e888f600b934_--
More information about the M3devel
mailing list