Linux-Development-Sys Digest #800, Volume #6 Wed, 9 Jun 99 01:14:00 EDT
Contents:
Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows (Christopher B. Browne)
Re: TAO: the ultimate OS (Jim Richardson)
Re: TAO: the ultimate OS (Chip Salzenberg)
Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows ("Max Reason")
Run time measurement with micro (or at least milli)-second (Virasit Imtawil)
Re: TAO: the ultimate OS (David Fox)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 Jun 1999 04:07:58 GMT
On Tue, 8 Jun 1999 16:58:35 -0000, Max Reason <[EMAIL PROTECTED]> posted:
>Christopher B. Browne wrote in message ...
>>> Do you think there should be two versions available, one for
>>> the majority who don't need source and prefer not to waste
>>> several megabytes of disk space - and another for the few
>>> who would "support" XBasic in the sense people are saying.
>>
>> All you need worry about, forcibly, is the source code. With the
>> *widespread* use of binary packaging tools like RPM and dpkg,
>> it is not at all unreasonable to expect someone to build a binary
>> package that will be conveniently installable. And someone on
>> the BSD side might build a "Ports" version. All of these will be
>> dependent on the source code, so what's important is always
>> the source...
>>
>> The bonus is that by letting someone else be responsible for
>> that, this gets an extra person or two involved, which can't but
>> be a good thing...
>
> I agree with that, but I missed something. Who would these
> extra person or two you mention be?
Nobody knows yet. But if there's enough interest in the software,
someone *will* do it.
>>>> for licensing, may i suggest a trip to www.fsf.org?
>>>
>>> I'll check that link out later tonight.
>>
>> The suggestion that you look to <http://www.perl.org> for info
>> on the "Artistic License" was another good suggestion; it is
>> *extremely* difficult to get unbiased evaluations of the common
>> "open source" licenses because almost everyone has a
>> significant bias of one sort or another.
>
> One thing that would help me would be a list of what are the
> natures of the significant biases, and the overall feelings
> people have about one vs another.
I'll pass, for now. There be big dragons here, and it will
take quite a lot of words to say anything about it.
>>>> I'd also prepare each separate document of the client's
>>>> source code to include the copyleft statements, along with
>>>> contact information in the document's header space...
>>>>
>>>> however, after reading about 400K of assembler code
>>>> in the source...
>>>
>>> Don't be too scared! That is 400K of assembly language
>>> source text. Most of that is comments - it's very heavily
>>> commented. I just looked at the xlib.o file made from it,
>>> and it's 74KB, which means the actual executable binary
>>> is probably only - what? 32KB to 64KB maybe. If people
>>> dislike assembly in an open source project on principal,
>>> all of it could be converted to XBasic - about 1/3 - 1/2
>>> of the assembly are core routines where speed matters
>>> (like super-fast malloc(), calloc(), free() routines) and the
>>> rest for historical reasons [translation: stupid decision].
>>
>> Do you have an assembler integrated in? If it takes a
>> proprietary assembler to get it assembled, that will be
>> something of a barrier...
>
> This takes a little explaining. When you develop programs
> in the development environment, XBasic emits executable
> binary directly into memory, then executes it - translation is
> directly from XBasic source-code to executable binary
> machine instructions. To make standalone executables
> XBasic generates an assembly language file and makefile.
> The assembly language generated by Linux XBasic
> assembles on whatever assembler was bundled with
> Caldera Linux 4+ years ago when I make Linux XBasic.
> This is probably the GNU assembler, but recently I got
> a new computer and don't have Linux on it to check.
> Anyway, I assume the assembler must be one of the
> standard freely available Linux assemblers. Right?
> The assembler for the Windows implementation IS
> non-standard, but an old friend of mine wrote it and
> it's based on something called yacc as I recall.
> Anyway, I have all the files required to build it, so it too
> can become part of the XBasic source code package.
It's very probably GAS, and that's very probably fine.
>> Note that the downside to assembler is that there are
>> increasing numbers of people not using IA-32-based
>> architectures, and the "general availability" of 64-bit
>> systems is fairly rapidly approaching. The *big* problem
>> with assembler is that it ain't portable. I suspect that if
>> the system becomes popular, an item on the "task list"
>> will be to make it portable...
>
> XBasic does NOT have an inline assembler. I've been
> roundly criticized for that many times. Your comments,
> however, seem to lean in my favor. Finally! :-)
You may not be too happy with what follows, but try to regard it as
friendly comment.
> Like I said, the assembly language can be recoded in
> XBasic and made totally "portable", since the rest of
> XBasic is written in XBasic already - without C library
> support but yes, of course direct Linux system calls.
That's somewhat unconventional; it is usually considered preferable to
go through LIBC, and the need to do so is getting greater as people get
more interested in portability. One of the design features of GLIBC 2
is that it provides a portability layer so that applications need not
go directly to a #include "sys/linux.h" or some such...
The more strongly you're tied to the kernel, the more vulnerable you
are to whatever Linus or Alan are working on...
> Nonetheless, your comments strike me as somewhat
> strange. Maybe I designed XBasic in a stupid way,
> but to port XBasic to an Alpha or Sparc or Merced
> requires making it emit code for the target CPU
> everywhere it emits code. That seems like lots more
> work than converting a small assembly language file.
Be aware that GCC can generate, for C, C++, Objective C, Ada,
Pascal, FORTRAN, and Chill, object code for a pretty *vast* array
of architectures. IA-32, MIPS, Alpha, SPARC, ARM, M68K, PowerPC, and
that's just the ones that are routinely used for Linux. IA-64 is
coming Real Soon Now as yet another selection.
There is starting to be commercial (or, more precisely, proprietary)
software for some of the non-IA-32 architectures, and that displays that
there are are enough of 'em out there as to make this a viable idea.
There may not be a resolution to the "cross-architecture support" issue
at this point in time, but you should keep it in mind.
Three years from now, when 64 bit CPUs that aren't IA-32 are *very*
commonplace, it would be a Bad Thing if XBasic was so tied to IA-32
that it became a bad choice of application platforms due to not being
compatible with the computer hardware of 2002. Three years is a long
time in some respects, but not in others...
> Originally I developed XBasic for a Motorola 88000
> workstation (running UNIX of course). That's a very
> nice 32-bit RISC CPU. When I made the Windows
> and Linux and UNIX implementations of XBasic for
> the 80486+ CPU, I had to live with only 8 registers,
> compared to the 32 I had in the 88000. Now maybe
> I am a stupid compiler designer, but for me it was
> more work to change XBasic to emit code for the
> 80486 from the 88000 than to rewrite that assembly
> language file. I was not aware that compilers could
> be effectively written so you simply plug in a new
> CPU architecture template (or something) and say
> presto-chango, emit efficient optimized code for
> this new CPU architecture. Of course I CAN see
> that going from one 32 register RISC CPU to another
> 32 register RISC CPU would not be as much work.
> And XBasic was very much designed to scale to
> 64-bit architectures without difficulty or problems
> with 32-bit vs 64-bit program compatibility. Anyway,
> that is the situation with XBasic - for better or worse.
>
> By the way, what is "IA-32-based architecture" mean?
> Does that mean Intel 80486/Pentium I, II, III - or what?
> Max
IA-32 stands for "Intel Architecture, 32 bit." That would
include such notables as:
- Intel 80386, 80486, "Anything with Pentium in the name," Xeon.
- AMD 5x86, K5, K6 (and variants), and probably K7.
- Cyrix CPUs from the days of the 80386 onwards.
- IDT Winchip.
- Rise Technologies' chip.
IA-32 is a really nice inclusive term that reasonably refers to them
all at once.
Contrast with IA-64, the identifier for Merced and successor generations
of 64 bit processors. (Merced is only the first generation.)
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (Jim Richardson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Tue, 8 Jun 1999 12:26:32 -0700
Reply-To: [EMAIL PROTECTED]
On Mon, 7 Jun 1999 22:57:12 GMT,
Vladimir Z. Nuri, in the persona of <[EMAIL PROTECTED]>,
brought forth the following words...:
>Nix ($}xinix{[email protected]) wrote:
>
>
>..."a wish list is not a design"
>
>
>I acknowledge this .. but a wish list that people agree on is a
>CONSENSUS.. a direction!! a map to the future!!
>something that all the "rugged invidividualist"
>programmers aound here deride as a sort of evil socialism or
>corporatism.
why must all the people agree with your wish list? If you want it.
Start writing it, release the code early and often, and coders will
come and make mods/suggestions.
Until there is some code one the table, it sounds like one more
"mission statement."
>
>so I have a long wish list.. so what? who has articulated
>these wishes as important before? no one has pointed me
>to any essays.. I await eagerly.
>
>
Well, I can't help there, I have not done any research into the subject,
maybe you have new ideas that are worth working on. Do so, if you expect
this huge groundswell of people to come and say "lead us" you are apt to
be disappointed. Throw some code together and get the ball rolling.
>--
>~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
>"in theory, there's no difference [EMAIL PROTECTED]
>between theory and practice, mad genius research lab
>but in practice there is!" http://www8.pair.com/mnajtiv/
--
Jim Richardson
Anarchist, pagan and proud of it
WWW.eskimo.com/~warlock
Linux, because life's too short for a buggy OS.
------------------------------
From: [EMAIL PROTECTED] (Chip Salzenberg)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 8 Jun 1999 23:25:00 -0400
Good ideas outnumber implemented good ideas by several orders
of magnitude. Thus the IETF motto:
"Rough consensus *and* working code."
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
-> Ask me about Perl training and consulting <-
"It's a dangerous game we play." "You mean, like, Jarts?!" //MST3K
------------------------------
From: "Max Reason" <[EMAIL PROTECTED]>
Subject: Re: Linux development tools - new : download freeware compiler with IDE and
GuiDesigner for Linux & Windows
Date: Tue, 8 Jun 1999 17:32:42 -0000
Martin Maney wrote in message <7jk62i$1di$[EMAIL PROTECTED]>...
>Max Reason <[EMAIL PROTECTED]> wrote:
>> Yes, the intro page was extracted from a long-ago XBasic flier that
>> therefore does has a commercial tone - but is also a useful overview.
>
> I think we'll have to agree to disagree about how helpful it is.
>
>> Nonetheless, I'm trying to be helpful, nothing else, so I have made
>> some changes to the web-pages (except the "offensive" overview)
>
> I didn't really find the overview offensive, just mostly useless.
> Like most advertising materials. :-(
Well, okay, we don't even have to disagree. But what information
WOULD be useful for you? You've convinced me I should rework
that page now that I've got most of the other support pages started.
> I'd suggest (if I haven't already) a simple, clear statement that the
> "pro" version is now freely available. ON whatever page you tend
> to direct folks to - that was the "overview" page, I think?
Yeah, the overview page was supposed to tell them enough to
decide whether they want to go to the documentation pages for
more detailed information, the FAQ page for common questions,
the download page to try it out, etc. Of course if the overview page
turns everyone away, what's the point of the rest, right? :-)
It must not stop everyone, however, since I've had 1300+ visits to
the download page in one month, and almost as many downloads.
Nonetheless, a useful overview is obviously a good idea.
>> I must admit I don't understand what you mean by that paragraph.
>> What do you mean by "free = unqualified". I really don't know what
>
> That was probably a bad choice of phrase.
>
>> you mean by that, but I thought Linux was free BUT qualified - in the
>> sense that certain restrictions apply. Also, I somehow suspect
>
> Unqualified "free" ought never to be used anywhere near software
> these days. :-( Linux and a large proportion of the software usually
> used with it - especially system utilties and basic tools - are "GPL-free",
> aka "libre" (I kind of like that - it's short yet distinct, although it's not clear
> how to translate it into certain other languages <grin>). What Xbasic
> appears to be is "beer free" - no charge for it, but no sources either.
> This is fine for games or stand-alone things, but not so good for tools
> that you would use to make other programs with: either real open source
> of some flavor (so you can fix it or pay someone to fix it if it's a show-stopper)
> or good commercial (so you can get the vendor to fix it - this may be more
> of an ideal than a reality, alas) terms are better here.
Well okay. Though I'm not sure how to translate "libre" to English,
it seems XBasic will fall into the "libre" free category as soon as
I figure out how to do that intelligently. Someone pointed me at
a Gnu Basic project just barely getting organized [seemingly] and
I sent them an introductory inquiry to see if there's collaboration.
Unfortunately their auto-mailer program seems to think I'm trying
to subscribe to their mailings! As soon as I get through to them,
maybe that'll lead to a method of "libre"-izing XBasic. If not, after
I hear from some more seasoned Linux people like yourself I'll
probably begin to grasp what "doing it right" means.
>> Linus has not agreed to answer every question everyone wishes
>> to ask - so in the sense you seem to mean, Linux is not supported.
>
> No, you've missed the point entirely. Linus doesn't HAVE to answer
> every question: we can ask an even more oracular voice, the source code.
> Actually, like asking the Greek Oracle, asking the source is not always the
> easiest way to get the answer you need in every case. ;-)
You mean some other poor sucker who already spend 100 hours
pouring through source code and tearing his hair out to solve the
same problem you now face --- and who is now kindly willing to tell
you how to fix the problem in 2 minutes - before he goes off and
shoots himself! Is that the greek oracle method. I like it! :-)
>> to answer questions, but... Actually, I have not read about how
>> the core Linux crew manages Linux, and for that reason I'm quite
>> ignorant (meaning "no knowledge from experience") about how
>> such management would be organized. That's why I'd prefer
>> someone with that knowledge/experience do it right.
>
> The open source approach is more along the lines of making
> the source available and seeing if anyone picks it up and does
> something exciting to it. Speaking of "scary", huh? <grin> You
> might want to look over the licenses - it sounds to me like you
> would probably prefer something along the lines of Larry Wall's
> "artistic license", which retains some control over what is allowed
> to be called "Product X" while retaining the key virtues of open source.
> www.opensource.org is probably a good starting point - there are
> as many definitions of "free" as there are people wanting to call some
> piece of software "free", though, so don't take OSI's word as gospel.
> Still, on the whole they do a pretty good job of surveying at least most
> of the field. www.fsf.org would be a good counterpoint to OSI's take
> on the issues. <evil grin>
I probably don't know all the scenarios I should worry about,
but here are the ones that have come to mind. I don't really
mind how many cool additions and features (and bug fixes)
people add to XBasic. Of course I'd like to see intelligent
and generally useful stuff, but hey, whatever. But I wouldn't
want somebody to say "hey, I don't like the way this statement
or standard library function works, so I'm gonna change it or
eliminate it --- and break ALL pre-existing XBasic programs.
Maybe this isn't as likely as it seems, since XBasic is written
in XBasic so most such moves would break XBasic too,
rendering the change self-defeating. Of course the demon
could rewrite those spots in XBasic that depend on the
"offensive" statement or function - which puts me back in
the "I don't want this to happen" situation where everyone
else who already has XBasic has to fix their programs to
work around this person who hates the statement so much
he's willing to stick it up everyone's DO loop.
What I really would like to hear from people is - what SHOULD
I worry about. I am so disconnected from community software
efforts that I sense I'm probably gonna worry about issues that
will never arise and get nuked by ones I never imagined.
> Nope. Huge IDEs aren't my kettle of fish. There are
> plenty of folks who have been wishing for something
> like this (sorry, I can't name any names, but this comes
> up all the time in this and other news groups). The purist
> approach would be to put the sources up with an appropriate
> (ie, that you're comfortable with) "free" license and wait for
> developments. For a large, "completed" project like this
> there may be little visible action for a while - less obvious
> rough spots to catch the eye, and a large body of code to
> assimilate.
Well, I hope some of these people contact me, express
the particular interests they have, and tell me what would
make them happy. That'll help. Probably it's time for me
to make an actual announcement that Linux XBasic "pro"
is now freeware and available for download - rather than
just tacking it onto miscellaneous messages people post
that seem related. Though I did not set-up to distinguish
downloads of Linux XBasic vs Windows XBasic, the
total number of downloads has shot up very substantially
since I mentioned XBasic on these two Linux newsgroups.
max
------------------------------
From: Virasit Imtawil <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Run time measurement with micro (or at least milli)-second
Date: 8 Jun 1999 22:22:46 +0100
Dear All,
I am sorry if this is not where I should write but I would like your
help. I am a beginner here. I use Redhat linux (kernel 2.0.32). I would
like to know how to measure CPU executing time within the C source code in
micro (or at least milli)-second resolution. I tried clock() command but
it's just second resolution which is extremely coarse. For example, I have
a C code like
main() {
double time_cnt = 0.0;
--;
--;
x = time_start();
---;
---;
---;
---;
y = time_finish();
time_cnt += y-x;
if ( time_cnt > limit )
break;
}
Something like this....is it possible to measure the time in executing any
portion or loop within the code and print it out? Anyone who has some code
to do this? How can I implement it?? I really have no idea....help me
please. Thank you very much for your help in advance.
Virasit
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: alt.os.linux,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 08 Jun 1999 21:46:57 -0700
"Hayden Walles" <[EMAIL PROTECTED]> writes:
> G. Sumner Hayes wrote in message <[EMAIL PROTECTED]>...
> >Associating code and data tends
> >to limit you to a single view of your data, precisely the sort
> >of problem you want to avoid in a good UI
>
> I notice you've told us this several times now. Since I'm not an HCI guru,
> perhaps you might consent to tell us _why_ you want to avoid this problem in
> a user interface.
A simple example would be the fact that you often want to use a
variety of tools to operate on a single document. If each document is
bound to a single tool you have a problem. And this type of problem
gets worse as you start thinking hard about the lower level details of
a system.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
