[M3devel] helo everyone - videotutorials for modula3

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Thu Jun 16 21:34:41 CEST 2011

Hi all:
but indeed if we were building such a cross-development environment like say eg I386_MINGW, else anything like that we would have several possible targets (for instance some application compiled under X Window and some others for native GUI, granted potentially the C compiler linker fits there) as AMD64_INTERIX, etc.
Tjis cases could create a problem to package everything in just one tar ball, it would be more a modular thing as you say, again I coincide that the cost of what we can host is better, but there are this issues we could somehow get into play. Anyway, it is maybe a cross-development issue rather than native issue, but it certainly begs some attention if I may say so.

Thanks in advance

--- El jue, 16/6/11, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: RE: [M3devel] helo everyone - videotutorials for modula3
Para: dabenavidesd at yahoo.es, "m3devel" <m3devel at elegosoft.com>, "Olaf" <wagner at elegosoft.com>
Fecha: jueves, 16 de junio, 2011 13:27


> > >> hing -- just the headers and
> > >> a list of symbols in libfoo.so=2C not the actual
> > code for libfoo.so.

I wasn't referring to "libm3.so" so much as "libc.so".
i.e. not stuff we build, but stuff we reference.

That is -- if you recall -- the thread "started" (I seemed to miss the start) bemoaning something about a dependency on postgres and postgres wasn't installed.
The postgres dependency should only be for building our postgres wrapper, not for installing anything.

On a private reply...apparently I left cminstall in the *.deb files, and I think that was an accident.
The original poster installed the .deb and ran cminstall.

As I said private and repeatedly pubically -- cminstall isn't very good at doing the very little it does.
And also, I did do the per-target work of finding where packages strongly tend to be installed, so that
the probing around by cminstall is less useful. Granted...stuff can still be in a variety of places.

Even if, e.g. /usr/opt is "standard" in some packaging system (NetBSD?), user might still
manually install to /usr/local or $HOME or $HOME/foo or whatever.

Ultimately I guess I guess the config files can and should be user-edited upon install.
AND to that end, there should be a better separation between simple-somewhat-likely-to-be-user-edited content
and gnarlier-less-likely-to-be-edited, and the possibly-not-sure-it-exists-must-not-be-edited

By which..I don't know...maybe the files should be broken up more, like:

 /cm3/bin/config/target/libraries (a text file, a quake snippet -- pick some extension) 
 /cm3/bin/config/target/c_compiler (ditto) 
 /cm3/bin/config/target/internal (ditto) 
 /cm3/bin/config/target/main? (ditto) 

 main would simply include(internal), c_compiler, libraries, in some order 

oops but there I went making things modular! :) 

..and...really..I'm not going to do this, for multiple reasons.

The current code is already somewhat well factored into small toplevel files that include
other shared and "gnarlier" files.

It takes merely like


in the toplevel file to trump the shared gnarly stuff.

We should possibly just put that in each file, commented out perhaps.

But even so, I don't like putting much of anything in I386_LINUX, AMD64_LINUX, PPC_LINUX, etc.
rather nicer to put stuff in Linux.common.


> Date: Thu, 16 Jun 2011 15:43:28 +0100
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; wagner at elegosoft.com
> Subject: Re: [M3devel] helo everyone - videotutorials for modula3
> Hi all:
> I think is just because of the project repository thing,a s In DEC SRC the vesta CM system, and had a cache of the copies in the laboratories and compiled for local machines (but they did have the AST cached, see:
> ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-168.pdf
>  I believe to help building large programs), I however don't know besides the test purposes where behind this specifically Juno-2, it seems they tests whether the configuration scheme was optimized to Juno µ-code programs, however still I don't think they necessarily did that but for another experiment of performance monitoring called PSpec used to monitor how was Juno-2 behaving in execution times mount also in Vesta in the JunoVM.
> BTW, if it doesn't matter what is the current working state of Juno-2 in Win32, this could be the most critical but appreciable piece between many others obviously more critical than it self.
> Thanks in advance
> --- El jue, 16/6/11, Olaf Wagner <wagner at elegosoft.com> escribió:
> > De: Olaf Wagner <wagner at elegosoft.com>
> > Asunto: Re: [M3devel] helo everyone - videotutorials for modula3
> > Para: m3devel at elegosoft.com
> > Fecha: jueves, 16 de junio, 2011 05:14
> > Quoting Mika Nystrom <mika at async.caltech.edu>:
> > 
> > > Jay K writes:
> > > ...
> > >> Besides that=2C there's a certain dumbness.
> > >> Compiling and dynamic linking against libfoo.so
> > ought to require almost not=
> > >> hing -- just the headers and
> > >> a list of symbols in libfoo.so=2C not the actual
> > code for libfoo.so.
> > >> That is basically how compile/link on Windows
> > works. But maybe not elsewher=
> > >> e.
> > > ...
> > > 
> > > SRC M3 used to work like this: m3ship would ship only
> > the .a/.so, the .i3
> > > files, and some sort of symbol table.  PM3
> > started shipping the sources,
> > > not sure why.
> > 
> > I think the only reason is to have fully indexed and
> > referenced
> > source documentation via Reactor/CM3-IDE/m3browser.
> > 
> > I don't really see how that is related to linking against
> > external
> > libraries though.
> > 
> > Olaf
> > --Olaf Wagner -- elego Software Solutions GmbH
> >            
> >    Gustav-Meyer-Allee 25 / Gebäude 12, 13355
> > Berlin, Germany
> > phone: +49 30 23 45 86 96  mobile: +49 177 2345
> > 869  fax: +49 30 23 45 86 95
> >    http://www.elegosoft.com |
> > Geschäftsführer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> > USt-IdNr: DE163214194
> > 
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110616/0bccc5a3/attachment-0002.html>

More information about the M3devel mailing list