<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>Basically, I hate the idea of tangling together multiple machine-dependent systems in the same files. Yes, it is verbose with duplicated functionality, but it *is* separable. I can delete one set of files without breaking builds on other targets. I hate the idea of C wrappers even more!</div><div><br></div><div>So, my position remains that while it is verbose having separate target-specific directories, at least they are independent and isolated.</div><div><br></div><div>I actually think your suggestion is much messier than the current situation!</div><div><br></div><div>On Apr 23, 2008, at 1:12 PM, Jay wrote:</div></span></span></span></span></span></span></span></span></div></span></div><div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: 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: 0; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">ok. stat is an evolutionary mess actually.</div></span></blockquote><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: 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: 0; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; "><br><br>Tony, Are you against having one Modula-3 definition of the type, arbitrarily defined (any order, no padding, omit the nanoseconds probably) and then wrappers in C to copy the data out? That is very simple and obviously correct and just a tad inefficient. I'm very much leaning toward this. Just for all live Linux variants for now, not anything else (until I see if they have messy slightly hard to read headers -- really, I can read them, or preprocess them, but I am a little off put, others would be more off put and checking my work becomes harder). I think there's gains to be in Cygwin too -- you can ask it for not all the fields and have it be faster, you know, if you don't need some complicated made up ino.<br><br>Either that, or I rather think I should work out the two or three struct declarations precisely and write non-copying wrappers in Modula-3 that call __lxstat64, __fxstat64, etc., copying the inlines out of the header.<br><br>I approach from both sides -- read the header, and have C code print sizes and offsets.<br><br>It's a little messy. Read the comments.<br>There is a version number parameter to an underlying wrapper function.<br>The wrapper is either inlined or statically linked.<br><br>I have to check if /usr/include represents all architectures, or just x86 and AMD64.<br>It could be that the fork is on 32 and 64.<br>It could also be that using stat64 makes it all a little simpler, but still a little messy. I have to see when then was introduced, I assume well before LINUXLIBC6 but I have to check. Even stat64 isn't the same between architectures though, it is split 32bit and 64bit..<br><br> - Jay<br><br><blockquote><hr>From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a><br>Subject: Re: [M3devel] naming conventions for split/composed interfaces?<br>Date: Wed, 23 Apr 2008 12:40:23 -0400<br><br><div><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><div><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><div>Yeah, but in this case they really are for the platform -- header files in /usr/include. I just want to make sure that we don't slice and dice in ways that multiply the confusion. Right now, if I know what platform I am on I know where to look in cm3/m3-libs/m3core/src/unix. I do try to use generic stuff where possible (witness my darwin-generic, darwin-ppc, darwin-i386, darwin-amd64).</div></span></span></span></span></span></span></span></span></div></span></div><br><div><div>On Apr 23, 2008, at 11:39 AM, Jay wrote:</div><br class="EC_Apple-interchange-newline"><blockquote><span class="EC_Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; "><div class="EC_hmmessage" style="font-size: 10pt; font-family: Tahoma; ">The point is to reduce massive duplication.<br><br>Sometimes we split on ostype, sometimes on wordsize, sometimes on the entire platform, sometimes otherwise.<br>Imagine if we always split on entire platform, what a mess that would be.<br><br>Upthread.i3 should be nearly identical across all platforms.<br> I know some platforms might have more functions, but the next level up is not split and is therefore consistent in what it uses, so no point in splitting the entire interface.<br>Let's not multiply everything out just to change a few lines.<br><br>There is too much duplication in the system imho and I'd like to see it reduced.<br><br> - Jay<br><br><br>> CC:<span class="EC_Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> From:<span class="EC_Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> To:<span class="EC_Apple-converted-space"> </span><a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a><br>> Subject: Re: [M3devel] naming conventions for split/composed interfaces?<br>> Date: Wed, 23 Apr 2008 11:33:00 -0400<br>><span class="EC_Apple-converted-space"> </span><br>> Generally, what I try to do is to make Uxxxxx.i3 files for every<span class="EC_Apple-converted-space"> </span><br>> corresponding C xxxx.h file. This way, as the C headers change it is<span class="EC_Apple-converted-space"> </span><br>> easy to figure out where things should go. Why do you need a platform-<span class="EC_Apple-converted-space"> </span><br>> specific name at all? Simply put it into a platform-specific<span class="EC_Apple-converted-space"> </span><br>> subdirectory which will then be selectively included by the parent<span class="EC_Apple-converted-space"> </span><br>> m3makefile. That way, we retain a consistent name for the files<span class="EC_Apple-converted-space"> </span><br>> containing relevant declarations *across* platforms. Remember, only<span class="EC_Apple-converted-space"> </span><br>> one of these subdirectories gets included in any given build (these<span class="EC_Apple-converted-space"> </span><br>> are part of the run-time). So, for simplicity's sake I would argue<span class="EC_Apple-converted-space"> </span><br>> that you are once more making unneeded complexity where simplicity is<span class="EC_Apple-converted-space"> </span><br>> needed.<br>><span class="EC_Apple-converted-space"> </span><br>> So, simply having a "linux-generic" directory, and "linux-amd64" +<span class="EC_Apple-converted-space"> </span><br>> "linux-ppc" + "linux-x86" subdirectories, each with "Upthread",<span class="EC_Apple-converted-space"> </span><br>> "Ustat", etc. should work just fine. What's the point in making it<span class="EC_Apple-converted-space"> </span><br>> more complicated?<br>><span class="EC_Apple-converted-space"> </span><br>> On Apr 23, 2008, at 11:20 AM, Jay wrote:<br>><span class="EC_Apple-converted-space"> </span><br>> ><br>> > So I'm fixing AMD64_LINUX Utypes.i3, Ustat.i3, etc.<br>> ><br>> > Look at what I did for example with Upthread.i3 vs.<span class="EC_Apple-converted-space"> </span><br>> > UpthreadMachine.i3.<br>> ><br>> > Ustat.i3 shall be mostly the same between PPC_LINUX, LINUXLIBC6<span class="EC_Apple-converted-space"> </span><br>> > (I386_LINUX), AMD64_LINUX, etc.<br>> ><br>> > However struct_stat will not likely be. It appears, though I have to<span class="EC_Apple-converted-space"> </span><br>> > double check, the difference cannot be abstracted out to pointer-<span class="EC_Apple-converted-space"> </span><br>> > sized integer types, that the fields are of varying orders.<br>> ><br>> > So I want to say:<br>> ><br>> > linux-i386/UstatPlatformSpecific.i3<br>> > TYPE struct_stat = ...<br>> ><br>> > linux-amd64/UstatPlatformSpecific.i3<br>> > TYPE struct_stat = ...<br>> ><br>> > linux-ppc/UstatPlatformSpecific.i3<br>> > TYPE struct_stat = ...<br>> ><br>> > linuxlibc/Ustat.i3<br>> > TYPE struct_stat = UstatsPlatformSpecific.struct_stat;<br>> ><br>> > My question is simply:<br>> ><br>> > What is the, or a good, naming convention for UstatPlatformSpecific?<br>> ><br>> > Note that it /could/ be that all but x86 have the same definition,<span class="EC_Apple-converted-space"> </span><br>> > so "PlatformSpecific", might be too, um, specific.<br>> > UstatMachine? (Similarly wrong, but maybe no matter, and shorter.)<br>> > UstatNotCommon? Sounds dumb.<br>> > UstatX? Not as bad as it sounds. There is a precedent. It self-<span class="EC_Apple-converted-space"> </span><br>> > documents the idea that there isn't an obvious good name.<br>> > UstatInternal? UstatPrivate?<br>> > It's not really about hiding, so much as implementation factoring.<span class="EC_Apple-converted-space"> </span><br>> > But implementation structure is an internal detail.<br>> > UstatF? (Friend?)<br>> > Ustructstat? no -- ideally, anything in existing Ustat.i3 that<span class="EC_Apple-converted-space"> </span><br>> > varies goess here, not necessarily just this type.<br>> ><br>> > I do not want fork entire files.<br>> > The system is composed of common and uncommon pieces.<br>> > I believe the decision where to split should be in general pushed<span class="EC_Apple-converted-space"> </span><br>> > down.<br>> > However not without judgement calls.<br>> > You know, there are things that must be shared, things that are nice<span class="EC_Apple-converted-space"> </span><br>> > to share, things that are more efficient to share, things that<span class="EC_Apple-converted-space"> </span><br>> > cannot be shared.<br>> > Type declarations are usually "must" but in this case largely<span class="EC_Apple-converted-space"> </span><br>> > "nice" (not Ustat, but e.g. Upthreads), and some parts of them<span class="EC_Apple-converted-space"> </span><br>> > "cannot".<br>> ><br>> > This split/compose pattern, you know, is a way to get something like<span class="EC_Apple-converted-space"> </span><br>> > #ifdef, without any language change or such.<br>> > It does make existing code harder to read, because it is broken up<span class="EC_Apple-converted-space"> </span><br>> > into more pieces, but code will always be broken up into pieces and<span class="EC_Apple-converted-space"> </span><br>> > never all in one place and always require some assumption or<span class="EC_Apple-converted-space"> </span><br>> > tracking down of what the next level down does (until you get to<span class="EC_Apple-converted-space"> </span><br>> > atoms, quantum physics, and all that), the thing is merely to decide<span class="EC_Apple-converted-space"> </span><br>> > on just what amount is the right amount (says Goldilocks.)<br>> ><br>> > - Jay<br>><span class="EC_Apple-converted-space"> </span><br></div></span></blockquote></div><br></blockquote></div></span><br class="Apple-interchange-newline"></blockquote></div><br></body></html>