Hello all,
I am on the LinuxBIOS list and my gut sense told me that a compiler that they
are developing called romcc might be a fit for Parrot.
Since Parrot uses CPU style assembler as its native language, it might make
sense to match it with a compiler that can take advantage of this.
Along
http://news.bbc.co.uk/hi/english/sci/tech/newsid_1156000/1156212.stm
This nuclear/dynamite stuff is making me sad.
Wanna contribute in the name of perl ?? Lets see... China + UN = $perl_revenue
Giving talks at YAPC is a no brainer, and I see the criteria of creating public
documents and the existance of a deadline being exceeding good
things.
Documenting the knowlege and preventing the authors from obfuscating the documents (by
accident, of course) will generate far to much noise
I am supporting regular GNU licensing to relieve the pain I am hearing about in the
commercial zone where folks are allegedly up to NG.
Also if we use the GNU license, then we dont have to worry about applications meant
for perl being written in some other less appropriate
language because
Using IBM's choice of Linux and Apache as an example, the compiler is not theirs, it's
GCC.
Also, when I was doing support for biochemical and statistical modelling at Merck, the
scientists choice was GCC over the HP native compiler.
(porting GCC to HPUX was one of my responsibilities)
I would like to do this, but I think its a bigger job than you imagine, and...
"I tend towards insanity from time to time. Good thing its only perl." (you can
quote me)
(It comes from stresses developing sysadm apps around the single largest depository of
human wealth. They actually
"David Grove" [EMAIL PROTECTED] wrote :
But.. but... but... we don't even have a design spec. I mean, we don't
even know for sure what Perl 6 is going to look like for certain, inside
or outside.
This is precisely why I proposed the BS level just below Development. In fact I'm
going to
Using the IBM article that Jarkko found as an example, core implementations of
different languages may have more in common with each other
than implemetations of the same language,
I think PPC is actually significant enough so that it should not be painted into a
perl-only corner.
Seeing
I have been using Cygwin, UWIN and now a ZSH tool set to create SSH1 access to servers
from Win32 boxes.
More recently, ports got closed between the Unix boxes yet we are able to access them
all from our workstations. What this has meant for me
is that I have to port all my monitoring,
Wow! You're good!
Thanks, can I quote you ??
However, the "marriage" part of your prediction is
already *mostly* true... future Python... same vein as Lisp
-- only the people who really grok Lisp can see it.
I totally disagree with your last point though.
Thats ok,
Perl has stayed
FTC = FCC (= FDA = DEA = FBI = DOJ = DOA = CIA = Ma_FIA = ...)
once you've lost it, [ simplicity, that is ] it's never
coming back
How true, I'm not holding my breath for CGI.pm divesment.
Simplicity to me as an integrator/admin means having set of binaries that can be
recompiled, or preferably configed, into diverse implementations
with uniform
On 28 Oct 2000 08:06:57 +0200, Ariel Scolnicov [EMAIL PROTECTED] wrote :
threaded code is so much slower; this can also be seen as
an indictment of threaded code).
Now I am really confused. This directly contradicts the Threaded Perl RFC.
My instincts still tell me we need two perl core
This thread seems to be winding down fttb**, Judging from the below, perl
multithreading [ I am guessing ] is simply syntatic sugar much the
same as Koch C++ is a wrapper for regular cc compiler.
This sounds nice,
Threading Perl bytecode would be nice about 98% of the time, and
If you get the chance, I would really grateful if you could translate the abstract
into lay terms, just confused by the concept of "low level perl"
Why??, perl is my only (byte) compiled language...
$thanks - (1000K)
I'm an admin, perl saved my life...
However, yesterday, some simple IO::Socket scripts failed to work on 5.6. I'm not
addressing that here but my resulting thought is now that the
distribution should only include such core components as are necessariy to define
perl's behavior.
Those
a design expressed in UML could be
implemented in a non-OO language.
Interesting concept... "expressing" perl in UML would certainly add depth to the
artistic license ;)
I think, though, that the core interface should be procedural.
I agree. We should not confuse OOD with OOP.
As in
VMS must die!
Hahahahaha !!!
Not to sound too, a, whatever...
but you rock,
Get it started, make it available, and I will format it into a pleasant (interactive)
web page, I promise !!!
(thinking faq-omatic)
I have personally agonized about the threading issue, basically w/o every writing a
usable script in it.
I would like to know where the archive is, its not really obvious, before comenting
that we may need two cores, on with one w/o.
cheers, john
Tom Christiansen wrote:
It [miniperl] isn't substantially smaller, so that does you no good.
The socket library seems to be the poster child for what to leave
out, but that's a weak argument
... it would make sense to design a
miniperl that can dynamically load the "expensive"
I really screwed this up, who has editable rights for the pages.
( .htaccess ?? )
On Tue, 12 Sep 2000 20:35:32 -0400, Bennett Todd [EMAIL PROTECTED] wrote :
I don't even want to embed the current perl in mutt; I'd love to
have a scripting and extension language embedded in there, but not
one that's bigger than all the rest of the application.
A couple years ago I wrote
=head1 TITLE
Data/Binary Dumping and Freezing
=head1 VERSION
Maintainer: John van Vlaanderen
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 210
Version: 1
Status: Developing
=head1 ABSTRACT
Allow Perl to create serialize both data and code from the
25 matches
Mail list logo
