> Yep. But when it comes to multithreading you can't assume the same
> behavior on e.g. single or multiprocessor systems anway.
> leo
Sounds like a user-land implementation should be default then, to guarentee
consistancy across hardware let alone machines. Software targeted for specific
uses c
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 c
Thought so... but it really makes sense, at least under the covers, if you think about
it.
> Simon Cozens wrote:
> > [Note: I've been asked to release this as editor of www.perl.com; I'll give
> > my *personal* opinions on the move later in the day or tomorrow.
>
> "Gotcha".
>
> Squawk,
> S
wiz & Dan Sugalski & wiz wrote:
> This is a start, which is very good, but I'm pretty sure that this is
> taking things from the wrong angle to some extent.
>
>o In general, if everyone's mostly familiar with just Unix's security model
>o I'd really, *really* urge you to read up on other models.
> > 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 f
> Respectfully, as with the other
> issues, let's please give Larry his time at bat with the RFC as it stands
> rather than second guessing ourselves again redundantly after the fact.
very good, here's your lollipop ;)
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 of
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)
Linu
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 smoth
"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
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 tha
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, distr
FTC = FCC (= FDA = DEA = FBI = DOJ = DOA = CIA = Ma_FIA = ...)
> 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 staye
>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 result
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 co
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
> sho
$thanks -> (1000K)
* It also means we can write bits of perl in Perl, and similarly not have
to care about this fact.
Granted, some developers are thick as a brick...
If you are writing perl in Perl, then, presumably, you would know this.
Excatly where is the added value, or is it purely for entertai
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...
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 should
> >The knowledge gathered from writing the modules Storable,
> >Freeze::Thaw, and Data::Dumper, should be studied very carefully.
Those are my lifeblood, that's why I proposed having them in the core as being key to
persistance and communication. I store in binary and
communicate with Data::D
> 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
How would the byte-compiled caches relate to the compiled C code XS'd into the
modules??
Could it be embedded, I think not, but please enlighten me.
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)
> VMS must die!
Hahahahaha !!!
I'm not sure where CORBA fits into the picture, frankly, it will probably never impact
my niche, which is dumb-ass operation$.
But one of the contractors here is thinking about switching to python to get the CORBA
implementation, he claims perl is not serious in that
direction.
The only reas
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
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 wr
I really screwed this up, who has editable rights for the pages.
( .htaccess ?? )
> > 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 "expensiv
=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 core.
I just subscribed this minute...
> >There's embedding and there's embedding. Embedding in an UNIX server
> >is different than from embedding in a RTOS microcontroller.
We're getting very close to blurring the line between microcontrollers and servers.
In the next few years the palm tops will h
34 matches
Mail list logo
