<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>In terms of OS technologies, yes the idea was quite revolutionary, most of that came frrom Rrichard Cownie, application Manager of the OS:<br>" Other prominent people on ARX were Steve Glassman (window system)" --may he rest in peace, died in alst October,- ", Carl Dellar (filesystem), Jon Gibbons (InterScript-based editor)."<br><br>They were led in the project by Jim Mitchell, see:<br>http://en.wikipedia.org/wiki/James_G._Mitchell<br><br>Trevor Morris and Mick Jordan were the actual compiler duys, very small group but brave group of people!<br>I give you all the email I interchanged with permission of the AM RC: <br>
Hi,<div><br></div><div>Hmm, off the top of my head, I don't remember anything called CAMEL -</div><div>do you have any idea what it was ? Something might come back to me.</div><div><br></div><div>I did work on the other OS project, I think that's the thing called ARX.</div><div>It was really crazy. Development was based in Palo Alto, California,</div><div>with a bunch of ex-Xerox PARC people led by Jim Mitchell. The original</div><div>idea was for a brand new incompatible-with-anything-else OS for</div><div>business computing, using write-once optical disks instead of magnetic,</div><div>with its own window system, its own transaction-based filesystem,</div><div>its own editor based on Interscript, and basically anything wacky that</div><div>anyone felt like working on. And it was all supposed to run on a machine</div><div>with 512KByte of DRAM.</div><div><br></div><div>I went out there for 6 months or so to work on the
"Application Manager" -</div><div>and I had never seen a windowing system, so I had no clue what the</div><div>hell I was doing. There were no documents worth a damn. Mitchell was</div><div>always just about to sit down and write the API's for the OS, but it</div><div>never happened. And they added Unix compatibility as a feature at</div><div>a late stage, and really no-one had any idea how to do it.</div><div><br></div><div>The whole thing was being developed using Acorn hardware and software -</div><div>fileservers based on 6502 processors, the Acorn EcoNet network, and</div><div>personal machines using early ARM boards. And there was no sensible</div><div>source code management. The most useful thing I did was to write a</div><div>program called "xfertree" which could sync up two file trees across the</div><div>network with minimal file transfers: if you copied a whole source tree</div><div>things weren't reliable enough
to get it done :-(</div><div><br></div><div>And the whole thing was supposed to use Modula-2+, with heavy use</div><div>of exceptions ... but the compiler was being developed at the same time</div><div>and didn't have the exception features yet ...</div><div><br></div><div>A total mess. The project thrashed around for a while until the guys</div><div>back in England got hardware and started essentially rewriting the BBC OS</div><div>into a mixture of ARM assembler and BBC BASIC - and that was what</div><div>became RISCOS. IIRC they hacked together the first version in just a</div><div>couple of weeks, though there was a lot of evolution later, led by</div><div>William Stoye, a super-smart guy.</div><div><br></div><div>Jim Mitchell, and I think many of the other ARX people, went on to join</div><div>Sun and do another mostly-disastrous OS project, the Spring OS.</div><div><br></div><div>As I say, I don't really remember "CAMEL", but I was
around the ARX</div><div>development and if you give me some hints it might jog my memory.</div><div><br></div><div>Regards</div><div> Richard Cownie</div><br>Thanks in advance<br><br>--- El <b>lun, 20/6/11, felipe valdez <i><felipevaldez@gmail.com></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: felipe valdez <felipevaldez@gmail.com><br>Asunto: Re: [M3devel] M3devel Digest, Vol 56, Issue 22<br>Para: "Daniel Alejandro Benavides D." <dabenavidesd@yahoo.es><br>CC: "Modula-3 developers" <m3devel@elegosoft.com><br>Fecha: lunes, 20 de junio, 2011 14:50<br><br><div id="yiv1681956513"><font face="courier new,monospace">Hi, Daniel.<br></font><div><div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace"><br></font></div><div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace"><br>
</font></div><div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace">the discussion is not about whether or not the announced (but yet undelivered) new windows file system, will handle such tasks. the problem is concerning, detecting the location of an currently installed program, in a cross platform way.</font></div>
<div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace"><br></font></div><div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace">I suggested a way, by implying that "windows solves it", but what my statement didn't attempt to convey, is that windows is a better solution what linux/unix, as an OS, or that it is better in every other aspect, and we should all switch (which is not the case).</font></div>
<div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace">I'm not surprised, that by the mere mention of the MS product, one is immediately reminded of its flaws, by the linux/unix advocates, but still, this is not the point at all.</font></div>
<div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace"><br></font></div><div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace"><br></font></div><div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace"><br>
</font></div><div><font class="yiv1681956513Apple-style-span" face="'courier new', monospace"><br></font><div class="yiv1681956513gmail_quote">2011/6/20 Daniel Alejandro Benavides D. <span dir="ltr"><<a rel="nofollow" ymailto="mailto:dabenavidesd@yahoo.es" target="_blank" href="/mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a>></span><br>
<blockquote class="yiv1681956513gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">Hi all:<br>if that's more important I would like roll back, can you have that, can you save/restore it?</td>
</tr></tbody></table></blockquote><div><br></div><div><br></div><div>yes, wel call them "backups".</div><div><br></div><div> </div><blockquote class="yiv1681956513gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top"> Interesting perhaps that was part of the idea of ARX OS, if you could roll back there is room for things like that, I think is quite possible since their<span class="yiv1681956513Apple-style-span" style="font-size: small;"> </span></td>
</tr></tbody></table></blockquote><blockquote class="yiv1681956513gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
cabinets where printed on optical mediums, so they were "fingerprinted" with time stamps even such a feature requires more than optical data, requires a file system,</td></tr></tbody></table></blockquote><div><br>
</div><div><br></div><div>storing a timestamp, requires a filesystem, what a revolutionary concept!, tell me more!</div><div><br></div><div> </div><blockquote class="yiv1681956513gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top"> BTW, what is FS in Win7 or 8, does it have that capabilities?<br></td></tr></tbody></table></blockquote><div><br></div><div>
I believe they use: create_date and modified_date, but I suppose your needs are much more esoteric and specific than what the program solved.</div><div><br></div><div>I for one have used version control successfully, but not for all the files, but rather for a small part of the filesystem, (my source files).</div>
<div><br></div><div><br></div><div>do you propose that having a rollback in the filesystem, is somehow related to the postgres location determination problem in any way?</div><div><br></div><div>if so, please let us know, I'm curious.</div>
<div><br></div><div><br></div><div> </div><blockquote class="yiv1681956513gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
Thanks in advance<br><br>--- El <b>lun, 20/6/11, felipe valdez <i><<a rel="nofollow" ymailto="mailto:felipevaldez@gmail.com" target="_blank" href="/mc/compose?to=felipevaldez@gmail.com">felipevaldez@gmail.com</a>></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">
<br>De: felipe valdez <<a rel="nofollow" ymailto="mailto:felipevaldez@gmail.com" target="_blank" href="/mc/compose?to=felipevaldez@gmail.com">felipevaldez@gmail.com</a>><br>Asunto: Re: [M3devel] M3devel Digest, Vol 56, Issue 22<br>Para: <a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>
Fecha: lunes, 20 de
junio, 2011 12:52<div><div></div><div class="yiv1681956513h5"><br><br><div><font face="courier new,monospace">I also think this is a non- obvious problem.<br></font><div><font face="'courier new', monospace"><br></font></div>
<div><font face="'courier new', monospace">in windows, there is the registry, which is al wasy the same path, and indicates the actual path of the files, does a facility like this exist in ubuntu?<br>
</font></div><div><div><br></div><div>what about: </div><div><br></div><div>$ which postgres</div><div><br></div><div>
does that yield good results?</div><div><br></div><div><br></div><div><br></div><div>2011/6/17 <span dir="ltr"><<a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel-request@elegosoft.com">m3devel-request@elegosoft.com</a>></span><br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send M3devel mailing list submissions to<br>
<a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a rel="nofollow" target="_blank" href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel-request@elegosoft.com">m3devel-request@elegosoft.com</a><br>
<br>
You can reach the person managing the list at<br>
<a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel-owner@elegosoft.com">m3devel-owner@elegosoft.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of M3devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: helo everyone - videotutorials for modula3 (Jay K)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 16 Jun 2011 23:26:45 +0000<br>
From: Jay K <<a rel="nofollow" target="_blank" href="http://mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>><br>
Subject: Re: [M3devel] helo everyone - videotutorials for modula3<br>
To: <<a rel="nofollow" target="_blank" href="http://mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a>>, m3devel <<a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>>, Olaf<br>
<<a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a>><br>
Message-ID: <COL101-W58C35DFF622F6A5810F33EE66A0@phx.gbl><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
<br>
> Anyway I think that is quite obvious if you want to link other libs<br>
<br>
You mean, like, to link to /usr/lib/libpostgres.so vs. /usr/local/lib/libpostgres.so vs. /home/jay/lib/libpostgres.so?<br>
Yeah, that is a problem. No good solution.<br>
Build-from-source is a solution, but not a good one.<br>
There's "origin", /etc/ld.so.conf, LD_LIBRARY_PATH, full paths in the executable.<br>
All are used, all have very significant advantages and disadvantages.<br>
I don't believe anyone has solved this problem.<br>
But I'm sure plenty of people believe they have.<br>
<br>
<br>
- Jay<br>
<br>
Date: Fri, 17 Jun 2011 00:11:00 +0100<br>
From: <a rel="nofollow" target="_blank" href="http://mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a><br>
To: <a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>; <a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a>; <a rel="nofollow" target="_blank" href="http://mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>
Subject: Re: [M3devel] helo everyone - videotutorials for modula3<br>
<br>
Hi all:<br>
yeah, you are correct the main problem might solved, but I was referring to was to the packaging in those cases where several implementations (not really Modula-3) might be available.<br>
<br>
CM problems that might have been solved too, I don't quite understand yet them as you. Sorry my ignorance if so. Anyway I think that is quite obvious if you want to link other libs you might want another model of pre-built-binaries or as you marked make everything compilation dependent procedures, which is something contrary to easy install and play setup (smarter developer, maybe individual packages for traditional users, that is, no geeks or both of them if could be fixed in the compiler setting) sense if I may say so.<br>
<br>
Thanks in advance<br>
<br>
--- El jue, 16/6/11, Jay K <<a rel="nofollow" target="_blank" href="http://mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>> escribi?:<br>
<br>
De: Jay K <<a rel="nofollow" target="_blank" href="http://mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>><br>
Asunto: RE: [M3devel] helo everyone - videotutorials for modula3<br>
Para: <a rel="nofollow" target="_blank" href="http://mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a>, "m3devel" <<a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>>, "Olaf" <<a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a>><br>
Fecha: jueves, 16 de junio, 2011 17:10<br>
<br>
<br>
<br>
<br>
<br>
Daniel, I don't understand you.<br>
We have pretty good support for cross builds.<br>
However it rests on underlying cross-compiler/linker though, and those are often not so easy to build/setup.<br>
We use whatever gcc is in $PATH, it can be a cross compiler, and you can set $CM3_TARGET / $M3CONFIG to point to whatever target configuration.<br>
If you don't want "gcc in $PATH" but instead want "target-gcc", that is easy and minor.<br>
We could support e.g. $CM3_CC.<br>
<br>
Probably it should be more like cm3 -target=foo.<br>
And the quake/config/cm3 code should perhaps probe for foo-gcc.<br>
Something like autoconf. But at each invocation, since you should be able to say cm3 -target=foo && cm3 -target=bar or even all at once cm3 -target=foo,bar.<br>
<br>
<br>
<br>
cm3 knows about "all" targets.<br>
It knows very little about any target, really.<br>
But some.<br>
I tried to remove its knowledge about jmpbuf size but so that failed.<br>
This is mostly better than the typical gcc usage where you have to configure and build separate gcc (gcc, cc1plus, etc.) for each target.<br>
(However binutils/ld/as are better now, you can perhaps configure for all targets at once.)<br>
Of course, cm3cg is gcc, so it still has that problem. Yuck. This is yet another problem that a C-backend would fix -- no more target-specific cm3cg.<br>
<br>
<br>
Much of the target-specific knowledge is in Quake/config files.<br>
There is more than I would like, but it isn't a ton.<br>
It is a less than it used to be, both in cm3 and the quake/config code.<br>
<br>
<br>
- Jay<br>
<br>
Date: Thu, 16 Jun 2011 20:34:41 +0100<br>
From: <a rel="nofollow" target="_blank" href="http://mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a><br>
To: <a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>;<br>
<a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a>; <a rel="nofollow" target="_blank" href="http://mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>
Subject: Re: [M3devel] helo everyone - videotutorials for modula3<br>
<br>
Hi all:<br>
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.<br>
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.<br>
Anyway, it is maybe a cross-development issue rather than native issue, but it certainly begs some attention if I may say so.<br>
<br>
Thanks in advance<br>
<br>
--- El jue, 16/6/11, Jay K <<a rel="nofollow" target="_blank" href="http://mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>> escribi?:<br>
<br>
De: Jay K <<a rel="nofollow" target="_blank" href="http://mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>><br>
Asunto: RE: [M3devel] helo everyone - videotutorials for modula3<br>
Para: <a rel="nofollow" target="_blank" href="http://mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a>, "m3devel" <<a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>>, "Olaf" <<a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a>><br>
Fecha: jueves, 16 de junio, 2011 13:27<br>
<br>
<br>
<br>
<br>
<br>
rambly...<br>
<br>
> > >> hing -- just the headers and<br>
> > >> a list of symbols in libfoo.so=2C not the actual<br>
> > code for libfoo.so.<br>
<br>
<br>
I wasn't referring to "libm3.so" so much as "libc.so".<br>
i.e. not stuff we build, but stuff we reference.<br>
<br>
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.<br>
The postgres dependency should only be for building our postgres wrapper, not for installing anything.<br>
<br>
On a private reply...apparently I left cminstall in the *.deb files, and I think that was an accident.<br>
The original poster installed the .deb and ran cminstall.<br>
<br>
As I said private and repeatedly pubically -- cminstall isn't very good at doing the very little it does.<br>
And also, I did do the per-target work of finding where packages strongly tend to be installed, so that<br>
the probing<br>
around by cminstall is less useful. Granted...stuff can still be in a variety of places.<br>
<br>
Even if, e.g. /usr/opt is "standard" in some packaging system (NetBSD?), user might still<br>
manually install to /usr/local or $HOME or $HOME/foo or whatever.<br>
<br>
Ultimately I guess I guess the config files can and should be user-edited upon install.<br>
AND to that end, there should be a better separation between simple-somewhat-likely-to-be-user-edited content<br>
and gnarlier-less-likely-to-be-edited, and the possibly-not-sure-it-exists-must-not-be-edited<br>
<br>
<br>
By which..I don't know...maybe the files should be broken up more, like:<br>
<br>
/cm3/bin/config/target/libraries (a text file, a quake snippet -- pick some extension)<br>
/cm3/bin/config/target/c_compiler (ditto)<br>
/cm3/bin/config/target/internal (ditto)<br>
/cm3/bin/config/target/main? (ditto)<br>
<br>
main would simply include(internal), c_compiler, libraries,<br>
in some order<br>
<br>
<br>
<br>
oops but there I went making things modular! :)<br>
<br>
<br>
..and...really..I'm not going to do this, for multiple reasons.<br>
<br>
The current code is already somewhat well factored into small toplevel files that include<br>
other shared and "gnarlier" files.<br>
<br>
It takes merely like<br>
<br>
SYSTEM_LIBS = ...<br>
<br>
in the toplevel file to trump the shared gnarly stuff.<br>
<br>
We should possibly just put that in each file, commented out perhaps.<br>
<br>
But even so, I don't like putting much of anything in I386_LINUX, AMD64_LINUX, PPC_LINUX, etc.<br>
rather nicer to put stuff in Linux.common.<br>
<br>
..Jay<br>
<br>
<br>
> Date: Thu, 16 Jun 2011 15:43:28 +0100<br>
> From: <a rel="nofollow" target="_blank" href="http://mc/compose?to=dabenavidesd@yahoo.es">dabenavidesd@yahoo.es</a><br>
> To: <a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>; <a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a><br>
> Subject: Re: [M3devel] helo everyone - videotutorials for modula3<br>
><br>
> Hi all:<br>
> I think is just because of the project repository thing,a s In DEC SRC the vesta CM<br>
system, and had a cache of the copies in the laboratories and compiled for local machines (but they did have the AST cached, see:<br>
> <a rel="nofollow" target="_blank" href="ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-168.pdf">ftp://apotheca.hpl.hp.com/pub/dec/SRC/research-reports/SRC-168.pdf</a><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thanks in advance<br>
><br>
> --- El jue, 16/6/11, Olaf Wagner<br>
<<a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a>> escribi?:<br>
><br>
> > De: Olaf Wagner <<a rel="nofollow" target="_blank" href="http://mc/compose?to=wagner@elegosoft.com">wagner@elegosoft.com</a>><br>
> > Asunto: Re: [M3devel] helo everyone - videotutorials for modula3<br>
> > Para: <a rel="nofollow" target="_blank" href="http://mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>
> > Fecha: jueves, 16 de junio, 2011 05:14<br>
> > Quoting Mika Nystrom <<a rel="nofollow" target="_blank" href="http://mc/compose?to=mika@async.caltech.edu">mika@async.caltech.edu</a>>:<br>
> ><br>
> > > Jay K writes:<br>
> > > ...<br>
> > >> Besides that=2C there's a certain dumbness.<br>
> > >> Compiling and dynamic linking against libfoo.so<br>
> > ought to require almost not=<br>
> > >> hing -- just the headers and<br>
> > >> a list of symbols in libfoo.so=2C not the actual<br>
> > code for libfoo.so.<br>
> > >> That is basically how compile/link on Windows<br>
> > works. But maybe not elsewher=<br>
> > >> e.<br>
> > > ...<br>
> > ><br>
> > > SRC M3 used to work like<br>
this: m3ship would ship only<br>
> > the .a/.so, the .i3<br>
> > > files, and some sort of symbol table. PM3<br>
> > started shipping the sources,<br>
> > > not sure why.<br>
> ><br>
> > I think the only reason is to have fully indexed and<br>
> > referenced<br>
> > source documentation via Reactor/CM3-IDE/m3browser.<br>
> ><br>
> > I don't really see how that is related to linking against<br>
> > external<br>
> > libraries though.<br>
> ><br>
> > Olaf<br>
> > --Olaf Wagner -- elego Software Solutions GmbH<br>
> ><br>
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355<br>
> > Berlin, Germany<br>
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345<br>
> > 869 fax: +49 30 23 45 86 95<br>
> > <a rel="nofollow" target="_blank" href="http://www.elegosoft.com">http://www.elegosoft.com</a> |<br>
> > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin<br>
> > Handelregister: Amtsgericht<br>
Charlottenburg HRB 77719 |<br>
> > USt-IdNr: DE163214194<br>
> ><br>
> ><br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a rel="nofollow" target="_blank" href="http://mail.elegosoft.com/pipermail/m3devel/attachments/20110616/8f0ac803/attachment.html">http://mail.elegosoft.com/pipermail/m3devel/attachments/20110616/8f0ac803/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
M3devel mailing list<br>
<a rel="nofollow" target="_blank" href="http://mc/compose?to=M3devel@elegosoft.com">M3devel@elegosoft.com</a><br>
<a rel="nofollow" target="_blank" href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br>
<br>
<br>
End of M3devel Digest, Vol 56, Issue 22<br>
***************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br>312-444-2124<div>301-578-7884</div><div><br></div><br>
</div>
</div></div></div></blockquote></td></tr></tbody></table></blockquote></div><br><br clear="all"><br>-- <br>312-444-2124<div>301-578-7884</div><div><br></div><br>
</div></div>
</div></blockquote></td></tr></table>