[M3devel] package groups question

Tony Hosking hosking at cs.purdue.edu
Fri Jul 31 06:28:55 CEST 2009


Randy,

I think this is a very useful exposition of the requirements for  
release distributions.  I trust that your concerns can be addressed by  
Jay and Olaf.  I must admit that, at this point, I have lost track of  
where things stand in the release installation process and hope soon  
to bring myself up to date.

-- Tony

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 31 Jul 2009, at 00:14, Randy Coleburn wrote:

> Jay:
>
> Thanks for your reply.  I really appreciate your patience in dealing  
> with all my questions, especially during this busy time preparing  
> for the release.
>
> In response, I offer the following and also ask a few more questions:
>
> My use of the term "minimal" is consistent with what has been  
> documented in the working release documentation.  Namely, that "min"  
> is the smallest distribution we plan to make available, versus "std"  
> that contains a "standard" distribution, versus "all" that contains  
> everything.
>
> Now as to the exact composition of "min" and "std" that is part of  
> my question.  I assumed someone (you, Olaf, Tony, ?) has defined  
> what these mean.  Further, if you look at PkgInfo.txt, it appears  
> that these definitions are recorded there, but again back to my  
> question as to whether these definitions are accurate, complete,  
> what the "cm3 community" wants/expects, and whether my understanding  
> of how they are used in the context of cm3 is indeed correct.
>
> I am well-versed in compilers and operating systems principles and  
> design, so I don't need a lecture on these fundamentals.  My line of  
> questioning is concrete with respect to the impending cm3 release.
>
> My use of the term "build" is in the context of "cm3 -build", and to  
> be useful, subsequently "cm3 -ship".
>
> As a software/systems engineer, I understand what you mean when you  
> say that the code is the documentation when there is no external  
> documentation.  However, I would hope you agree that no external  
> documentation is generally a bad thing.  Hence my questions.  I'm  
> not a python code writer yet, though I'm confident I could be, given  
> some time to learn.  Thus, I can't presently rely on reading a  
> python script as documentation.  I am confident that if you, Olaf,  
> Tony, or someone can confirm or correct my understanding of what  
> I've posed as the way to install the "min" distribution on Windows  
> and "build" the rest, that I can and will be able to document this  
> process externally for others to review.  We can then check scripts  
> to see if they deviate from the documentation and make changes (to  
> either scripts or documentation) as needed to reflect reality.
>
> You state that I have not defined the "goal."  Let me attempt to  
> make this obvious.  I'm not trying to upset the apple cart here or  
> change the way you work to achieve progress/success.  My goal simply  
> is to "understand" wrt the impending release so I can document, and  
> so I can "do the right thing" to make this work correctly on my  
> system.  We can discuss in the future how things should change for  
> the next release.
>
> Thanks for help with my 13-steps.  I have some comments and a few  
> more questions below.
>
> WRT #1, Yes, I know I may not need all of Visual Studio, but most  
> users will just choose the typical installation.  If we have  
> specific minimums that need to be present, we should identify  
> (document) those for users who choose to customize their installation.
>
> WRT #2, you have to start somewhere.  If we have both "min" and  
> "std" distributions, one can choose which to start with, but your  
> discussion of which parts to trim out of "min" should not be left to  
> the end user.  The release team needs to establish what constitutes  
> "min".  My "opinion" is that "min" should contain only what is  
> necessary for a working cm3 compiler, given the dependency on the  
> platform-specific linker.  Using "min" one should be able to build  
> (cm3 -build -ship) all other packages.  Anything added to "min" that  
> isn't necessary to accomplish building the remaining packages would  
> be considered superfluous, in my opinion.  Some amount of  
> superfluous on a given platform may be tolerable in order to reach  
> consistency among all supported platforms regarding the composition  
> of "min".  Thus, if cm3cg is needed for "min" on some platforms, but  
> not all, it is tolerable (IMO) to make it a standard component of  
> "min" on all platforms.
>
> WRT #3, point taken.  However, unless we have an easy way to specify  
> and checkout only those parts of the tree relevant to a particular  
> platform, checking out everything ensures you haven't missed  
> something that is going to cause problems later.
>
> WRT#4, although doc may not be needed to run cm3, it is needed for  
> folks to reference and understand cm3.  This is a long-standing  
> gripe of mine that we don't make the installation of doc part of the  
> typical installation.  The naive user new to cm3 normally expects to  
> get some documentation.  If the default is no documentation, how  
> does the poor sap know how to get the documentation and install it?   
> Also, cm3ide, does have links to the doc folder.  If you click on  
> these links and they are broken, the average user is going to rate  
> cm3 as a poor product and move on to something else.  Why create a  
> problem for the new user?  Give him the documentation he needs by  
> default and let the expert user remove it if it is unwanted.  I know  
> that Critical Mass's 4.1 installation put the doc folder there.   
> When did someone decide it wasn't appropriate for the default  
> installation?
>
> WRT#5, examples is needed for cm3ide.  Right now, my bet is that  
> most everyone in the cm3 community doesn't know they should copy the  
> examples folder to the root of their cm3 installation.  That's  
> because Reactor wasn't open-sourced until recently as cm3ide.  Right  
> now the only documentation about this is a README file buried in the  
> repository and even that wouldn't be there if I hadn't put it  
> there.  Again, don't create a problem for the new user.  The  
> "typical" installation choice should install it by default.  Let the  
> expert user choose to remove it as part of a custom install if it is  
> not wanted.
>
> WRT#6, agree.  That's why I wasn't specific on how to do it, but for  
> the newbie, it would probably be best to list at least one way.
>
> WRT#7, agree.  I was just stating my interpretation of what you had  
> communicated to me earlier about setting up config properly.
>
> WRT#8, ok, but you do get an error message if the folder exists  
> already.
>
> WRT#9, ditto #7
>
> WRT#11, now we are finally getting to the meat of my questions.  So,  
> if I understand you correctly, you are saying that building the  
> "min" group of packages does not recreate for me exactly what is  
> being published as the "min" distribution.  In my view, we have a  
> conflict of terminology here that needs to be cleaned up.  So what  
> exactly is "min" as defined in PkgInfo.txt if it doesn't represent  
> the minimal binary install?  Furthermore, if I want to use cm3 to  
> build the sources for the compiler itself, it would seem from your  
> comments that "min" won't do it.  Which packages need to built, and  
> in what order, to recreate cm3.exe ?
>
> Again you ask about the goal here, so let me be more explicit.   
> Given that cm3 continues to evolve and that minimal distributions  
> are created at unpredictable intervals, if one wants to ensure the  
> cm3 compiler is up-to-date with the latest sources, one would want  
> to start with some existing cm3 installation and build and ship the  
> compiler's source package(s) along with any other packages where a  
> dependency exists.  In these instructions, I started with obtaining  
> the latest "min" distribution, then grabbed the current source tree,  
> so I want to proceed from this point to build a current cm3 compiler  
> and any other requisite components to again create a "minimal"  
> installation on my platform.  From there, one can build some/all of  
> the remaining packages.
>
> WRT#12, the repeat is due to my prior understanding.  Perhaps this  
> is incorrect, or perhaps the recent changes have made this  
> unnecessary.  But, it seems my understanding of how to rebuild  
> cm3.exe is flawed given your response to #11.  Are you saying I  
> should use "front" to build cm3.exe?  Am I the only one to whom all  
> this is unclear?  Again, we need to document for understanding.
>
> WRT#13, not sure what you mean by "sort of".  What are the caveats?
>
> Regarding your comment at the end about scripts, I will respectfully  
> choose to disagree with you and hope that we work together to  
> improve documentation.  After all, if we all get run over by a  
> truck, what we know in our brains isn't available to others unless  
> we've documented it somewhere.
>
> Thanks for your patience in putting up with all my questions!   
> Thanks also for all you are doing for cm3!
>
> Regards,
> Randy Coleburn
>
>>>> Jay K <jay.krell at cornell.edu> 7/30/2009 4:11 PM >>>
>
>
> Randy, the short answer is:
>
> Find a goal state in a graph, which you haven't clearly done, walk  
> that graph from the bottom up, and if there are circularities (there  
> are, you need to have cm3 first, before you can build cm3), you need  
> to download prebuilt files from somewhere (cm3 and mklib).
>
>
> Everything else is filling in the details of the goal state,  
> discovering the circularities, and that we have the graph recorded  
> in a redundant fashion in pkginfo.txt. The real data is the  
> m3makefiles.
>
>
> longer answer:
>
>
>
> Randy, what is a "minimal" distribution? You have't defined the goal.
> What is "build"? You haven't defined the goal.
> I could just say: "Whatever you need, to build it, just download it  
> from here."
>
>
> I'll define it as some arbitrary very minimal compiler and runtime  
> set, specifically m3core and libm3.
> But you can have working Modula-3 programs certainly without libm3.
> And some Modula-3 programs will have a GUI so will want more  
> libraries.
> What is "minimal"?
> And depending on future changes, the steps might change.
>  Or maybe just pkginfo.txt will change.
> If there is no documentation and there is code, the code is the  
> documentation.
>
>
> A lot of the code is declarative -- you look at the import  
> statements in m3makefile.
> For given package foo, say "cm3", you walk the list of imports  
> transitively

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


More information about the M3devel mailing list