I hear what Vass is saying, but making it a sibling of modules and calling it modules-minimal seems like the most informative organization to me. It means typing an extra '/' or '-' because tab-completion won't be able to get any further than "modules", but I don't view that as a bad trade-off.
greg On Wed, 22 Jan 2014, Brad Chamberlain wrote: > I considered moving it under for similar (but less important to me) reasons, > but didn't > like (a) the implication that it was part of the normal modules setup and (b) > the lack > of symmetry. If others feel similarly about minimal-modules (or any other > combination > including the current) I'm open to that. I think it's a little unfortunate > not to share > prefixes (don't naming schemes often optimize the common part first on > computers?), > but not enough to feel religious about it. > > -Brad > > ________________________________________ > From: Vassily Litvinov [[email protected]] > Sent: Wednesday, January 22, 2014 7:32 PM > To: chapel-developers > Subject: Re: [Chapel-developers] [Chapel-commits] SF.net SVN: chapel:[22575] > trunk > > I'd like to request moving the minimal modules dir to under modules/, > e.g. trunk/modules-minimal --> trunk/modules/minimal. The current setup > messes with tab extension in my most-commonly-used tab extension scenario. > > An alternative would be to rename trunk/modules-minimal to > trunk/minimal-modules. Which has the side benefit of improved readability. > > Vass > > > -------- Original Message -------- > Subject: [Chapel-commits] SF.net SVN: chapel:[22575] trunk > Date: Wed, 22 Jan 2014 21:55:58 +0000 > From: <[email protected]> > Reply-To: <[email protected]> > To: <[email protected]> > > Revision: 22575 > http://sourceforge.net/p/chapel/code/22575 > Author: bradcray > Date: 2014-01-22 21:55:57 +0000 (Wed, 22 Jan 2014) > Log Message: > ----------- > Add support for a "minimal modules" compilation mode > > [reviewed by Kyle and partially by Greg] > > This commit adds support for a developer flag, --minimal-modules, in > which Chapel programs are compiled with a minimal amount of internal > and standard module support. This means that the language will be > virtually crippled (since so much of Chapel is defined within > modules), but it permits a developer to work on compiler > transformations in the core of the language without having to worry > about getting all of the internal/standard modules to compile properly > before evaluating their result. > > As an anecdote, I've been wondering recently about changes to the way > we (1) represent ref intents and (2) implement assignments within the > compiler, but in changing either concept, it can take so long to work > through all of the issues that arise in the internal modules that it's > hard to determine whether I'm making progress or not. With the > --minimal-modules flag, I was able to make a simple change to the > compiler to try issue 1 above and see its impact on the generated code > without wrestling through all of the issues that would have arisen > using the full set of internal modules. > > Of course, in some sense, this is just postponing the inevitable, but > the hypothesis is that it enables you to see that you're making a > correct/reasonable change earlier than you might otherwise be able to > determine if you were compiling the normal modules in full. Over > time, it may also be a means for us to determine which parts of the > internal/standard modules are particularly brittle or antiquated > w.r.t. the current language definition/compiler architecture, and > make them less so. > > The general strategy here was to make a clone of modules/internal > (called modules-minimal/internal) and then to rip out all but the most > essential components. When compiling with --minimal-modules, we use > that clone rather than the normal modules. The intent is that the > minimal-modules directory will not be bundled in the release since > it's a developer feature and just adds clutter to the top-level > directory. > > One design decision was to avoid changing the interface between the > runtime and compiler-generated code/modules in order to avoid having > to maintain different builds of the compiler when using > --minimal-modules vs. not. > > What remains in modules-minimal are six modules that correspond to > their full-blown counterparts, and make the following definitions: > > ChapelBase.chpl: > - proc =() : in its most generic form > - _ref : the standard ref class/type mechanism > - chpl__initCopy() : in its most generic form > - chpl__autoCopy() : in its most generic form > - chpl__autoDestroy() : in its most generic form > > PrintModuleInitOrder.chpl: expected by the compiler, but empty here > > ChapelStandard.chpl: expected by the compiler, now use's the next 3 > modules: > > ChapelTaskTable.chpl: > - chpldev_taskTable_*() : called from the runtime, all no-ops now > > MemTracking.chpl: > - chpl_memTracking_returnConfigVals() : called from runtime, now a > no-op > > ** One important note here is that, in order to avoid bringing in > SysCTypes.chpl along with everything it requires, I hard-coded > some arguments that are actually size_t to be uint(64) which is > a non-portable solution, but probably sufficient for most > developers to use (the audience for this patch) and unlikely to > cause any significant problems given that the function is a no-op > anyway. If this does give anyone hassles, let me know and we > can consider other options. > > ChapelUtil.chpl: > - chpl_main_argument : the argument type passed to chpl_main() > - chpl_rt_preUserCodeHook : a call into the runtime prior to user code > - chpl_rt_postUserCodeHook : a call into the runtime after user code > > The effect of taking everything else out is that none of Chapel's more > exotic types which are defined using modules are available (i.e., no > ranges, domains, arrays, tuples, sync/single, atomics). As a result, > parallelism is similarly unlikely to work (since it relies on > synchronization types internally). Similarly, basic/core operations > like +, -, *, /, ... casts, etc. are not defined due to their reliance > on module code. > > Naturally, a developer can incrementally add such functionality back > to their copy of modules-minimal, or to a specific test, but it won't > be included by default (for fear of there not being a clear place to > draw the line). > > > Apart from the modules themselves, here are the changes involved, by > file: > > runtime/src/chplmemtrack.c > -------------------------- > as mentioned above, the routine in MemTracking.chpl is now a no-op, so > I changed the initializations of some variables here so that they'd > have legal/appropriate values whether or not this routine did anything. > > > compiler/util/files.cpp > ----------------------- > made the module search path switch between 'modules-minimal' and > 'modules' depending on whether or not --minimal-modules is thrown. I > made all of the normal search paths use this same base directory, even > though most of the subdirectories under modules-minimal don't exist. > My rationale was so that if a developer wanted to replicate some of > the other module files in their usual subdirectories it would be easy > to do so. Ultimately, we may want the ability to specify a root > module directory via a compiler flag, but I didn't go that far here. > > > compiler/include/driver.h > compiler/main/driver.cpp > ------------------------- > added the new --minimal-modules flag and an fMinimalModules global to > store its state > > > compiler/main/config.cpp > ------------------------ > when compiling with --minimal-modules, stubbed out the checks for some > standard configs because they're not defined in this mode > > > compiler/passes/filesToAST.cpp > ------------------------------ > when compiling with --minimal-modules, stubbed out the error thrown if > we don't find standard module-defined types like _array, _tuple, etc. > because they're not defined in this mode > > > compiler/AST/astutil.cpp > ------------------------ > protect 'object' from being dead-code eliminated. The compiler relies > on its presence, but usually it gets preserved automatically through > the creation of classes in the internal modules. Now that we don't > create any classes there, we need to special-case it. > > > compiler/passes/buildDefaultFunctions.cpp > ----------------------------------------- > when compiling with --minimal-modules, don't deal with endcounts in > main() (because it relies on synchronization types that aren't > supported in this mode); and don't create default I/O routines for > records (because QIO isn't supported). The former is a necessity; the > latter is probably just a case of avoiding pointless work (i.e., > I'm guessing it wouldn't hurt to re-enable it, but didn't bother > trying). > > > compiler/AST/astutil.cpp > compiler/passes/addInitGuards.cpp > compiler/resolution/functionResolution.cpp > --------------------------------- > when running with --minimal-modules, I stubbed out the code relating > to printing the module initialization order for simplicity and fear > that it relied on QIO. Turns out that it doesn't relate to QIO (I > think) and probably could be re-enabled, but the simplicity argument > still sticks. If the routine doesn't exist (and it doesn't when > compiling with --minimal-modules), gPrintModuleInitFn will never be > assigned, so these files now stub out the related actions when it's > NULL. > > > test/compflags/bradc/minimalModules > test/compflags/bradc/minimalModules/minModDeclPrint.good > test/compflags/bradc/minimalModules/minModFnRefArg.chpl > test/compflags/bradc/minimalModules/COMPOPTS > test/compflags/bradc/minimalModules/minModFnRefArg.good > test/compflags/bradc/minimalModules/minModDeclPrint.chpl > --------------------------------------------------------- > added a few tests that I used while developing this, just to lock the > behavior in, should the key interfaces change > > Modified Paths: > -------------- > trunk/compiler/AST/astutil.cpp > trunk/compiler/include/driver.h > trunk/compiler/main/config.cpp > trunk/compiler/main/driver.cpp > trunk/compiler/passes/addInitGuards.cpp > trunk/compiler/passes/buildDefaultFunctions.cpp > trunk/compiler/passes/filesToAST.cpp > trunk/compiler/resolution/functionResolution.cpp > trunk/compiler/util/files.cpp > trunk/runtime/src/chplmemtrack.c > > Added Paths: > ----------- > trunk/modules-minimal/ > trunk/modules-minimal/internal/ > trunk/modules-minimal/internal/ChapelBase.chpl > trunk/modules-minimal/internal/ChapelStandard.chpl > trunk/modules-minimal/internal/ChapelTaskTable.chpl > trunk/modules-minimal/internal/ChapelUtil.chpl > trunk/modules-minimal/internal/MemTracking.chpl > trunk/modules-minimal/internal/PrintModuleInitOrder.chpl > trunk/test/compflags/bradc/minimalModules/ > trunk/test/compflags/bradc/minimalModules/COMPOPTS > trunk/test/compflags/bradc/minimalModules/minModDeclPrint.chpl > trunk/test/compflags/bradc/minimalModules/minModDeclPrint.good > trunk/test/compflags/bradc/minimalModules/minModFnRefArg.chpl > trunk/test/compflags/bradc/minimalModules/minModFnRefArg.good > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Chapel-commits mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-commits > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
