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.
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
> 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
--- 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
-pu
--- 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 a
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 com
>+ 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
> 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 alternati
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 requir
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/ "Th
et, but isn't
the failure 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 th
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 t
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:
&
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
-DL
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"
>&
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 r
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 w
> --- 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=/ ) {
> +#
Jarkko Hietaniemi wrote:
> Jarkko Hietaniemi wrote:
>
>>>io/io_unix.c does not compile because socklen_t is not defined.
>>>
>>>According to the standards, is needed to get socklen_t.
>>>
>>>One could try including that the right way into
The latest changes by Leo seem to have fixed this one, and similarly
#37338 and #37337.
-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
>
>
>
Jarkko Hietaniemi wrote:
>>io/io_unix.c does not compile because socklen_t is not defined.
>>
>>According to the standards, 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 co
>>
>>
>
>
> Jarkko,
>
> Does this issue still occur on tru64?
Works in Parrot 0.3.0.
> -J
>
>
>
> io/io_unix.c does not compile because socklen_t is not defined.
>
> According to the standards, 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:
>
> --- io/io_uni
>> 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
>
>
>
> 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
>
>
>
>
nd/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
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 inst
Tru64 is 64-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.i
around to updating
the CPAN FAQ a bit.
--
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this
special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
out needing to be told. They
> may follow "priorities" (which may derived 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 <[
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 Hietani
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 n
ed to be sent to $CC,
>>not to $LD. The command being called 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 remo
es for example here (blame HP for the awful URLs):
http://h30097.www3.hp.com/docs/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
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
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 PROTECT
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/ "Ther
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
s an AMD Duron,
that's about 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
personally aimed at you: I have been griping 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
> 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 W
e pre-converted, but that seems to be contrary
> to Parrot's usual MO.
>
> Let me know. I'm happy to do it either way, and I'll look at modifying
> the other bit-string 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
>
> 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
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 whet
>>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
> 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, no
If someone after Parrot 1.0 wants 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
>>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
d
>>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/
>>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
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 ot
> 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 re
Dan Sugalski wrote:
> At 7:57 PM +0300 4/27/04, Jarkko Hietaniemi wrote:
>
>> > 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 thin
> 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 accent
>>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
back when I checked the embedding interface in.
Something like
typedef struct Parrot_Interp_s {
...
} Parrot_Interp;
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 struc
>>>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 othe
>>>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.
>
>
> ... but only for constants.
Yeah, I was going to propose the Phaistos disc signs for
> 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 ra
> 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.
> Well, yeah, but... where the executable is ought, honestly, to be
> irrelevant. If I've stuck Parrot in /usr/bin it seems unlikely that
> I'll have parrot's library files hanging off of /usr/bin.
Bah. BAH, I say. The /usr/bin/parrot is of course a symlink
to, say, /platform/os/version/parrot
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 relocat
> 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
> hash slices aren't used much at all.
People *always* overgeneralize.
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
>>
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 exa
>>This is GCC on Gentoo: gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4
>>3.2.3-r4, propolice).
>
>
> Since the ICU static libs (".a"s) have C++ inside, we need to link with
> a C++-aware linking. Try setting:
>
>link => 'c++'
>
> in config/init/hints/linux.pl and see if that fixes it.
Yeah,
> 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 C where it's needed?
>
> e.g.
>
> use German;
> my $gi = "i";
> use Turkish;
> my $ti =
>
> (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.)
"where does it end?", because the logical 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
tation detail.
Once we get levels 0 and 1 working, we can worry about bolting 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
>>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
> 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
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" a
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
>&
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 w
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.
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
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
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")
or its platform moral equivalent.
Saves *time* and *space*.
> > 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
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 c
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 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
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 fil
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 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&#x
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, whe
ime soon, I'm 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
e
bytecode being different, I think only a non-aligned pointer could work
as the cursor.
--
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
e=8,
ptrsize=8, ptr_alignment=4 byteorder=12345678,
nv=double, numvalsize=8, doublesize=8
My longsize would be 8.
Note: if you have Tru64 you will need the attached (and submitted
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 +0000, 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&#x
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
1 - 100 of 460 matches
Mail list logo
