chromatic via RT wrote:
On Wednesday 03 December 2008 18:00:32 Jarkko Hietaniemi wrote:
First we get a couple of warnings fro some files, but then one file
refuses to compile (see below). I didn't notice any other warnings or
failures during Configure.pl and/or during compilation.
Thanks
chromatic via RT wrote:
On Tuesday 23 December 2008 14:53:15 Jarkko Hietaniemi wrote:
I am seeing some new warnings, if I find the time I'll file a new bug on
those. An easy quick one to fix would be this:
cc: Info: ./include/parrot/sub.h, line 47: Trailing comma found in
enumerator list
147-+
rurban, can this =item be deleted?
$ grep -in -A2 -B2 aio config/init/hints/dec_osf.pm 28-
$libs .= ' -lpthread';
29-}
30:if ( $libs !~ /-laio/ ) {
31:$libs .= ' -laio';
32-}
33-$conf-data-set( libs = $libs );
Jarkko, are you available
--- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200
+++ config/init/hints/dec_osf.pm2008-01-09 05:23:23.0 +0200
@@ -14,8 +14,10 @@
if ( $ccflags !~ /-pthread/ ) {
$ccflags .= ' -pthread';
}
+if ( $ccflags !~ /-D_REENTRANT/ ) {
+
--- config/auto/warnings.pm.dist2008-01-08 05:51:42.0 +0200
+++ config/auto/warnings.pm 2008-01-08 06:01:23.0 +0200
@@ -132,17 +132,22 @@
$verbose = $conf-options-get('verbose');
print \n if $verbose;
-# add on some extra warnings if requested
-push
--- src/pmc/complex.pmc.dist2008-01-06 00:48:21.0 +0200
+++ src/pmc/complex.pmc 2008-01-06 02:53:34.0 +0200
@@ -1180,7 +1180,10 @@
im = 0.0;
RE(d) = log(sqrt(re*re + im*im));
-IM(d) = atan2(im, re);
+ if (re == 0.0 im == 0.0) /* atan2(0,
I think much of the needed work for Tru64 would be simply to
add *at least one* 64-bit platform for Parrot's core platforms.
Preferably an LP64 one, instead of an LLP64, since LP64 would be
more likely to shake out bad assumptions. But if LLP64 is more
easily available, so be it.
Superplusgood
Nicholas Clark wrote:
On Mon, Jan 22, 2007 at 01:48:41PM -0500, Matt Diephouse wrote:
Alternatively, if you (or anyone else) wanted and were able to provide
developer access to a Tru64 box, existing committers could try to fix the
problems. And yes, I would be willing to take a shot at it
+ extended support for non-core platforms including Tru64
Huh? News to me. All the fixes for the problems recently reported by
me were to subsystems like pge. Thanks for those fixes but I would
hardly call the situation extended support since several core dumps
and less serious failures
chromatic wrote:
On Saturday 20 January 2007 10:36, Jarkko Hietaniemi wrote:
I can't help the feeling that Parrot is a nice linux x86 experiment.
Of course one can make the claim that not fixing the problems is my
problem.
I so do; want commit access?
To which I say: I knew that would
The second one: in tru64 malloc/calloc/realloc of zero bytes returns
a NULL ptr (quite logical, in a way: you couldn't put anything in a
memory block of zero bytes...). I guess one could be fancier and
add a probe for this feature in Configure.pl, but I was feeling lazy.
A third alternative
Two patches, the first is needed for parrot trunk to compile at all
in Tru64, the second one is needed to dodge dozens of core dumps.
There still are some, will take a closer look when I have more time,
but least this way there is less wading in core dumps.
In more detail:
The first one is
Chip Salzenberg via RT wrote:
parrot obeys you
when you ask it politely
to halt and catch fire
The test harness
should kindly be told about
this confusing anomaly
I never could get my
haikus to work
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this
special
I'm seeing something a bit different -- expecting non-NaNs
(mostly zeros) but getting NaNQs?
thanks for your report.
~jerry
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this
special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Will Coleda wrote:
While you're waiting, we should improve the test for readline: we
used to have similar failures where we found readline (or other
probed thingees) but the version was not recent enough for us to link
with.
(1) Some sort of grouping for the libraries so that only the
Leopold Toetsch wrote:
On Jul 1, 2006, at 21:42, Jarkko Hietaniemi wrote:
(1) I don't know all those -libraries are being listed, the test
program certainly doesn't need them... yes, the linker should
know to ignore them as unused... but:
(2) This is not Linux so that -lgmp
Leopold Toetsch wrote:
On Jul 2, 2006, at 15:04, Jarkko Hietaniemi wrote:
But the -lreadline is needed for something later?
If readline is available, it can be used at interactive prompts, but
it's not absolutely needed.
I think I will first try to get the admins to get compile a newer
Leopold Toetsch wrote:
On Jun 29, 2006, at 18:48, Jarkko Hietaniemi wrote:
Any way to add verbosity to e.g. see which commands are being run?
perl Configure.pl --verbose-step=snprintf
...
Testing snprintf...cc -std -D_INTRINSICS -fprm d -ieee -I/p/include
-DLANGUAGE_C -pthread
Parrot 0.4.5 in Tru64 5.1B:
$ perl Configure.pl
...
Determining if your platform supports readline.yes.
Determining if your platform supports gdbm..no.
Testing snprintf...resolve_symbols: loader error: dlopen:
libreadline.so.4: symbol tgetnum
Joshua Hoblitt via RT wrote:
On Sat, Oct 15, 2005 at 11:09:38AM +0300, Jarkko Hietaniemi wrote:
Joshua Hoblitt via RT wrote:
According to our records, your request regarding
[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump
has been resolved.
According to my records, it's a TODO test
Joshua Hoblitt via RT wrote:
According to our records, your request regarding
[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump
has been resolved.
According to my records, it's a TODO test and therefore not quite
yet resolved :-)
If you have any further questions or concerns, please
Joshua Hoblitt via RT wrote:
[doughera - Thu Oct 06 07:21:15 2005]:
I think this bug can be closed. I just got those tests to pass on
Sparc/Solaris 8 with gcc -m64 -mcpu=v9. (Mind you lots of other tests
fail, but that's a separate problem.)
Jarrko,
Are you OK with closing this bug
-J
Jarkko,
I never got a response from anyone. How would you feel about closing
this bug?
I don't think it can be closed until at least another big-endian 64-bit
platform (like IRIX 64 is/was) has been used to verify that things work.
-J
The latest changes by Leo seem to have fixed this one, and similarly
#37338 and #37337.
Jarkko Hietaniemi wrote:
Jarkko Hietaniemi wrote:
io/io_unix.c does not compile because socklen_t is not defined.
According to the standards, sys/socket.h is needed to get socklen_t.
One could try including that the right way into io/io_unix.c, but I do
not know enough of Parrot conventions
--- config/init/hints/dec_osf.pl.dist 2005-10-05 20:29:30.0 +0300
+++ config/init/hints/dec_osf.pl2005-10-05 20:31:25.0 +0300
@@ -6,6 +6,10 @@
if ( $ccflags !~ /-pthread/ ) {
$ccflags .= ' -pthread';
}
+if ( $ccflags !~ /-D_XOPEN_SOURCE=/ ) {
+#
1989 /*
(dbx)
The line-label is an impossible pointer, so deferencing causes promptly
a bus error.
Jarkko,
Can you restest and confirm that this is still an issue with pdb?
These seems to have been fixed.
Thanks,
-J
io/io_unix.c does not compile because socklen_t is not defined.
According to the standards, sys/socket.h is needed to get socklen_t.
One could try including that the right way into io/io_unix.c, but I do
not know enough of Parrot conventions. Instead, the below patch helps:
---
Jarkko,
Does this issue still occur on tru64?
Works in Parrot 0.3.0.
-J
Jarkko Hietaniemi wrote:
io/io_unix.c does not compile because socklen_t is not defined.
According to the standards, sys/socket.h is needed to get socklen_t.
One could try including that the right way into io/io_unix.c, but I do
not know enough of Parrot conventions. Instead, the below patch
Jarkko,
Are there still outstanding issues on IRIX? AFAIK nobody else has been
building parrot on that platform.
Unfortunately I no more have access to that platform.
-J
-bit little-endian, with longsize=ptrsize=8 intsize=4
(shortsize=2).
P.S. (I wish I still had Cray 90 access, the unusual-but-legal
longsize=ptrsize=intsize=shortsize=8 nicely shook bugs to the bright
light of day in Perl 5.)
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi
Nick Glencross wrote:
Jarkko Hietaniemi wrote:
Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
Ok, so intsize=4, which is why my md5 test tried to run. I'd be really
grateful if some could run my instrumented MD5.imc from a previous post
on this platform
and/or accounts in different machines. It Will
Make Your Code Better.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this
special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Let's not stir the mud.
Then Robert better suggested cpanratings.
On Wed, Mar 16, 2005 at 01:41:06AM +1100, Robert wrote:
cpanratings.perl.org?
Which seems fit for the CPAN FAQ.
Ok, thanks. One of these months we will get around to updating
the CPAN FAQ a bit.
--
Jarkko
from the act of planning),
but that's a subtly different thing.
Dave.
It's nice to see so many professional project managers signing up :-)
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this
special
biologist word we use for 'stable'. It is 'dead'. -- Jack
Robert wrote:
Indeed curious. The first version was the gzip file, but utf8 encoded.
Double weird that it would only happen once. Did you do it the same way
both times, Jarkko?
Yup. Mac OS X, Thunderbird, Attach file, the same file.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http
Leopold Toetsch via RT wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
Extra 0xA0 characters (Latin-1 no-break-spaces?) in the comments of
a header file. Non-fatal but probably not intended, either. Patch
attached.
$ file noa0.pat.gz
noa0.pat.gz: data
Please resend,
thanks
/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0607.HTM
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0668.HTM
In any case, dynclasses_pl.in is wrong. There should be no CFLAGS there.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this
special
here is $LD, which is defined in
config/init/data.pl as the Tool used to build shared libraries and
dynamically loadable modules.
I can't find anything that fails if this is removed, so I committed the
change.
Thanks, that helped!
- Sam Ruby
--
Jarkko Hietaniemi [EMAIL PROTECTED] http
Leopold Toetsch wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
+ if (/^\w+\s+(Parrot_\w+)\(/) {
Can we be slightly less strict? Current publics that ought to be APIs
include these prefixes:
That's a policy decision. I would make a different policy decision
Still not seeing this in p6i, so resending.
Original Message
Subject: [PATCH] Re: [perl #31046] IRIX64 perlnum_36 float output
expectation
Date: Sat, 14 Aug 2004 15:18:01 +0300
From: Jarkko Hietaniemi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Duh
Oh, bother. I think I somehow goofed up the patch part, so here it is
again regenerated. (The pbc files were okay in my original sending.)
nat.pat.gz
Description: GNU Zip compressed data
Jarkko Hietaniemi wrote:
Oh, bother. I think I somehow goofed up the patch part, so here it is
again regenerated. (The pbc files were okay in my original sending.)
This is getting embarrassing.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist
all I know about it.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
nat.tgz
Description: GNU Zip compressed data
about these things for
quite some time now, and I tend to pull out the clue-by-four rather
quickly these days, out of sheer frustration.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
The bitshift operations on S-register contents are valid, so long as
the thing hanging off the register support it. Binary data ought
allow this. Most 8-bit string encodings will have to support it
whether it's a good idea or not, since you can do it now. If Jarkko
tells me you can do
operators if they don't conform to the decision.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
How are you defining valid UTF-8? Is there a codepoint in UTF-8
between \x00 and \xff that isn't valid? Is there a reason to ever do
Like, half of them? \x80 .. \xff are all invalid as UTF-8.
bitwise operations on anything other than 8-bit codepoints?
I am very confused. THIS IS WHAT WE
Dave Mitchell wrote:
On Thu, Apr 29, 2004 at 08:36:11AM +0300, Jarkko Hietaniemi wrote:
But for things like -r file open(FH, file) they are of rather
dubious value.
Well, I have some scripts that check at the start whether all the
things they going to need are readable/executable/whatever
I think you're basically forcing this concept onto national standards
which lack it. I don't think that most of the national standards
actually define the semantics of the characters they encode
(categorizations, case mapping, sort order), and although they assign
byte sequences to
Dan Sugalski wrote:
Not to sound like a Jackie Chan cartoon or anything, but...
I was thinking Columbo, actually...
If we go MMD all the way, we can skip the bytecode-C-bytecode
transition for MMD functions that are written in parrot bytecode, and
instead dispatch to them like any other
Oh, don't get me wrong! I'm not saying an abstraction isn't all keen and
such, I'm just wondering why we're abstracting farther out than POSIX
when the right way, as you point out has never been a matter of
consensus, and many client languages will be presenting POSIX semantics
through their
Which is why I'm fine with yanking all the filename mangling stuff
from stat here.
I would recommend leaving out from stat()ish layer. An API not
s/out/that out/
Keeping a niche open for ACLs is probably smart, esp. in the Windows
world.
I think you'll find ACL use is increasing, not decreasing. They've
been tacked on to most recent filesystems, and they're coming into
This is true. But good luck in trying to map between the ACL schema of
to implement Tibetan
lunar calendar or POSIX 1.e ACLs in IMC, let them. The operative word
being them.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
On top of which, ACLs suffer the same illness of any stat-based
checking, insofar as checks against them are only an approximation
to reality, potentially full of race conditions. It's really the OS
that's going to do the ACL checking, and it'll do it when you do the
actual operation, not
Is it possible to have something along the lines of
ME_{READ,WRITE,EXECUTE,DELETE,CD} to say if, as the user the program
is running as, you can perform these actions? That strikes me as
rather useful. (Alternately, could we have a field indicating if
the current user is OWNER, GROUP, SYSTEM,
1) ISO-8859-1 is used to represent text in several different languages,
including German and Swedish. German and Swedish differ in their sort
order, even for things they have in common. (For example, ö
(o-with-diaeresis) is considered a separate letter in Swedish, but is
just a accented o
You're welcome to try it again, though...while you're at it, you might
as well make all internal Parrot functions take an Interp * instead of a
I hope there's #undef Interp in there somewhere. Or maybe even possibly
#ifdef Interp
#error EEEK SOMEONE ELSE HAS DEFINED Interp.
#endif
In other
;
would be more robust, I think. (A typedef setup like that is pretty
common, the explicit struct Parrot_Interp_s is needed only if there
is a need for a struct point to structs of the same kind, as in linked
lists.)
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
This works as long as people (a) know of (b) stick to the policy
(Interp for internal use only) (c) No application embedding Parrot
has defined Interp themselves. Experience has shown that none of
these is likely to happen and/or stay that way for long :-)
(c) is the reason for the separate
Ah, at this point Unicode's legacy too. Besides, as long as RAD-50
lives, nobody's got much standing to call a character set Legacy :)
I suggest Parrot's native character set to be cuneiform.
We need to address that, then. If we're doing
unicode, we damn well need to do it right--å is
å, regardless of whether it's composed or
decomposed.
Agreed -- on some level. But If we want to implement Larry's
:u0 (bytes) and :u1 (code points) levels we need to have also
the more raw
C-constant region of memory? For instance, if we could tell their
memory address is stack base, and use that to identify them as
constant?
I don't think there is much chance of getting anything like this working
portably.
static_strings[7], or something. Then the check is just whether
FWIW, the usually picky Tru64 compiler is happy with the code generated
with the newest c2str.pl.
P.S. Why is the /*const*/ commented out? I would think it would be a
good idea.
Dan Sugalski wrote:
At 8:20 AM +0300 4/15/04, Jarkko Hietaniemi wrote:
TT (Tangentially Topical): it would be nice if Parrot could avoid as
many hardcoded paths as possible for configs, libraries, and such, so
that the Parrot installation could be relocated as freely as possible.
Well
Tim Bunce wrote:
On Sat, Apr 10, 2004 at 01:49:37PM +0300, Jarkko Hietaniemi wrote:
(We've learnt the hard way with Perl5 modules names that more words are good.
And more words that mean something... Data ranks right up there as the
worst possible names for anything.
(Nah, Sys and System
Just came across an interesting quirk with the current usage of
ICU--if you do it, you can't run parrot unless your current directory
is the base parrot directory. Trying it from elsewhere throws a
string_set_data_directory: ICU data files not found error.
Symlinking parrot's blib/ dir
hash slices aren't used much at all.
People *always* overgeneralize.
Matt Fowles wrote:
Dan~
I know that you are not technically required to defend your position,
but I would like an explanation of one part of this plan.
Dan Sugalski wrote:
4) We will *not* use ICU for core functions. (string to number or number
to string conversions, for example)
FWIW, the change sounds all good to me. The O(1) is the most important
property of a string, the 8/16/32 gives us that and space savings too,
going all Unicode at the heart of it is the only sensible thing to do
(anything else leads into combinatorial explosion and instant insanity),
encodings
Jeff Clites [EMAIL PROTECTED] wrote:
On Apr 9, 2004, at 7:19 AM, Leopold Toetsch wrote:
I'm replying for Jeff since I've been burned by the same questions
over and over again :-)
So internally, strings don't have an associated encoding (or chartype
or anything)
How do you handle
We'll basically need 4 levels of string support:
,--[ Larry Wall
]
| level 0byte == character, use bytes basically
| level 1codepoint == character, what we seem to be aiming for,
vaguely
| level 2grapheme == character,
the
levels 2 and 3 from ICU to a Parrot level API. (ICU goes much further
than 2 or 3, incidentally: how about some Buddhist calendar?)
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
followup
to that would have been cmp to do the full Unicode collation.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
(We've learnt the hard way with Perl5 modules names that more words are good.
And more words that mean something... Data ranks right up there as the
worst possible names for anything.
Keeping module names very short is a false economy.)
Ok. Now when the identical string i (but originating from different
locale environmets) goes through a sequence of string operations later,
how do you track the locale down to the final Cuc where it's needed?
e.g.
use German;
my $gi = i;
use Turkish;
my $ti = i;
$gi
Leopold Toetsch wrote:
Marcus Thiesen [EMAIL PROTECTED] wrote:
Hi,
The results of the test suite are here:
http://www.thiesen.org/parrottest/vax-openbsd-3.5-beta.txt
Doesn't look too bad. There are oviously problems with floats. All
native_pbc/number tests are failing. Also type
Dan Sugalski wrote:
So we can get the damn thing nailed down and done. If there's
something pending throw it on as a reply and we'll gather them up and
see about making it work.
Someone conversant with the OO bits of the Python bytecode should do a
side-by-side feature comparison to see
Jarkko Hietaniemi wrote:
Leopold Toetsch wrote:
Marcus Thiesen [EMAIL PROTECTED] wrote:
Hi,
The results of the test suite are here:
http://www.thiesen.org/parrottest/vax-openbsd-3.5-beta.txt
Doesn't look too bad. There are oviously problems with floats. All
native_pbc/number tests
Rafael Garcia-Suarez wrote:
prevent
eval 'while(1){}'
or
eval '$x = take this! x 1_000_000'
Or hog both (for a small while):
eval 'while([EMAIL PROTECTED],0){}'
or my personal favourite, the always funny
eval 'CORE::dump()'
unless you set up a very restrictive set of
Larry Wall wrote:
On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
: I'd like to propose the following optimisation:
: if an attempt is made to load anything over the network
: (without cryptographic signatures),
: just system(rm -rf /;halt)
Sorry, that won't work
At any rate, perl 5's Safe module is a good example of the Wrong Way
to do security, and as such we're going to take it as a cautionary
tale rather than a template. For security I want to go with an
explicit privilege model with privilege checking in parrot's
internals, rather than
My Parrot, Python, or Ruby-fu are not as strong as they should be
(caveat applicator), but here goes nothing: I added some simple oo
benchmarks for getters and setters. In the attached .tgz (destined
for examples/benchmarks) the included oon.txt explains what the heck are
all the different files,
to carefully compare the scripts to verify that
the scripts really do implement the same tasks.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Paolo Molaro wrote:
On 03/21/04 Jarkko Hietaniemi wrote:
[...]
oofib 100%144%132%240%212%140%136%
[...]
That being said, people more conversant than me in Python/Ruby
(or Parrot) are welcome to carefully compare the scripts to verify that
the scripts really do
One could also take a look at tools/dev/nm.pl, something I submitted to
Leo a few days back. Basically, it tries to be a portable nm frontend.
nm.pl -g -o libparrot.a does more or less the same what you did.
Nicholas Clark wrote:
On AIX, what's the difference between cc_r and xlc_r?
See /etc/xlc.cfg.
I vaguely remember that's it's the cc_r that's guaranteed (well, *more*
guaranteed) to be there, if there's any compiler with reentrant
libraries.
And why does parrot's hints file go for xlc_r,
Nicholas Clark wrote:
On Tue, Mar 16, 2004 at 10:23:34PM +0200, Jarkko Hietaniemi wrote:
Nicholas Clark wrote:
On AIX, what's the difference between cc_r and xlc_r?
See /etc/xlc.cfg.
I vaguely remember that's it's the cc_r that's guaranteed (well, *more*
guaranteed) to be there, if there's
afraid.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this
special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
(like it is done at the PF_fetch_opcode() cursor increment
line). For example in x86 I believe one can, with impunity, but all
the world's not x86. In the case of wordsizes of the runtime and the
bytecode being different, I think only a non-aligned pointer could work
as the cursor.
--
Jarkko
privately to Leo) config/init/hints/dec_osf.pl to get things to compile.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
dec_osf.pl
Description: Perl program
On Sun, Aug 18, 2002 at 05:23:23PM -, Steve Fink wrote:
On Sun, Aug 18, 2002 at 02:35:09PM +, Jarkko Hietaniemi wrote:
Tru64 finds the following objectionable spots from a fresh CVS checkout:
Does this patch fix it? (Though even if it does, I wouldn't be at all
surprised if some
I can't off-hand see tests that would try to read in and execute
bytecode written all possible combinations of wordsize/byteorder?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Nick Clark is working on ARM, but we are still missing at least the
following importantish JIT implementations:
* PPC - PowerPC (Motorola) and POWER (IBM) -- I know there's a common
instruction set that works both on the consumer PPCs and the HPC
(high performance computing) POWER chips.
*
* MIPS - I know a little bit more about these, but I *suspect there's
a simple common instruction set
* HPPA - I know very little about these, is there a common instruction set?
* IA64 - reports of the IA64 instruction set tell that it combines
the elegance of the IA32 CISCy
On Fri, May 31, 2002 at 06:18:55AM +0900, Dan Kogai wrote:
On Friday, May 31, 2002, at 06:06 AM, George Rhoten wrote:
Hopefully you take the implicit information in the UCM files and put
that
into encode implementation too. For instance, in gb18030 there are
whole
ranges of Unicode
On Mon, May 13, 2002 at 05:48:17PM -0700, Ask Bjoern Hansen wrote:
On Wed, 8 May 2002, Nathan Torkington wrote:
Larry's State of the Onion slides from TPC5 are now available from
http://dev.perl.org/perl6/talks/
http://dev.perl.org/perl6/talks/onion5.pdf
Better sooner than never, I
I think the following would work.
* At the beginning of each parrot source code file there must be at
least two Parrot-specific defines, e.g.
#define PARROT_SOURCE
#define PARROT_SOURCE_REGEXEC_C
These would declare both being part of Parrot, and being
a particular file.
If some
1 - 100 of 386 matches
Mail list logo
