On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
> +int main(int argc, char **argv) {
> + printf("%d/%d", sizeof(${iv}), sizeof(${nv}));
> + return 0;
> +}
$Config{ivsize} not good enough for ya, then? :)
--
You are in a maze of little twisting passages, all alike.
On Thu, Sep 20, 2001 at 04:30:34AM -0400, Michael G Schwern wrote:
> And all of the tests fail with "This isn't Parrot bytecode!"
That's what I like to see. Thanks.
--
I've looked at the listing, and it's right!
-- Joel Halpern
On Thu, Sep 20, 2001 at 01:57:51AM -0700, Brent Dax wrote:
> No, because the user may have chosen a different value for IV. For
Oh, yep, fair enough. That makes sense.
> example, I may have chosen 'long long' in Perl 5 but 'long' in Parrot to
> be safe (IIRC, we're still having 64-bit issues)
the instructions. Comments?
It also means you *have* to allocate a new string each concat. That
sucks.
> ps should i start filing bug reports in rt if my assembler bugs
>aren't being fixed? ;-)
Yes, yes, yes.
Simon
--
The course of true anything never does run smooth.
-- Samuel Butler
On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
> This might help a bit.
It does; Parrot is now working to at least some degree on Tru64.
Andy, I love you and I want to have your children.
--
void russian_roulette(void) { char *target; strcpy(target, "bullet"); }
On Thu, Sep 20, 2001 at 09:22:50AM -0400, Michael G Schwern wrote:
> > That's because assemble.pl hasn't been patched yet to use the right
> > pack_type. You can either apply my patch from yesterday or you can
> > hand-patch the pack_type for 'i' to be 'q'.
>
> This one?
> http:[EMAIL PROTECTED]
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote:
> So, if you're running on one of the core platforms, please check out a *clean*
> CVS copy, try and build and post the output of make test.
FWIW, here's the current state of Tru64:
Failed TestStat Wstat Total Fa
On Thu, Sep 20, 2001 at 10:38:10AM -0400, Andy Dougherty wrote:
> This patch does two only somewhat related things.
>
> Parrot/Opcode.pm: Change the hard-wired assumption that sizeof(nv) =
> 2*sizeof(iv) to a PConfig-type computed value.
>
> Parrot/Test.pm: Change it to run with the perl that
I'm seriously investigating the possibility of changing IV and NV to something
more readable.
(But for those of you who are following language-dev, don't tell 'em because
then they'll think they've won. ;)
--
I don't understand how people can think SCSI is anything more quirky
than a genius wi
On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> I don't want to do int->pointer casts anywhere in the source if we can
> possibly avoid it. Yech.
In which case, do we *need* a type that can hold both.
--
"Darkly hinting of head hitting desk"
-- Megahal (trained on asr)
On Fri, Sep 21, 2001 at 02:50:45AM +0200, Mattia Barbon wrote:
> Parrot::Smoke 0.01 has just been released.
> It works on Win2k and Linux, but it should work
> in most Unices.
This is very cool! Thank you very much.
--
Putting heated bricks close to the news.admin.net-abuse.* groups.
--
m applying
> this, but I figure people might as well check it over anyway.
Excellent, thanks; sorry I was so quick to apply Andy's patch while you
were working on this.
> sub check_manifest {
ExtUtils::Manifest?
Simon
--
People in a Position to Know, Inc.
On Fri, Sep 21, 2001 at 10:18:31AM +0100, Leon Brocard wrote:
> Leon Brocard sent the following bits through the ether:
>
> > Attached are trivial comment fixes for two files.
>
> Oh go on, I know we're in a feature freeze but this is a doc
> patch. Can someone apply these please?
Doc patches a
On Fri, Sep 21, 2001 at 01:21:28PM -0400, Gregor N. Purdy wrote:
> I've continued to play with the DO_OP simplification patch I posted
> before. I've removed the op info stuff from the op func struct per
> suggestions from Dan.
Very nice, but can I remind you and everyone else that we're trying
t
On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> Doing this by hand with -O3, you can see a speedup of around a factor of 45
> over an unoptimised runops loop, so it's definitely worth doing in some
> cases...
Cool! Parrot JIT!
But that tells us *just* how time-consuming our ru
This is never set, although it is (indirectly) tested for. Here's
a patch.
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.14
diff -u -r1.14 Configure.pl
--- Configure.pl2001/09/21
13, 15, 17
Failed 7/23 tests, 69.57% okay (-2 skipped tests: 14 okay, 60.87%)
I guess that's not very fine, come to think of it, is it?
Simon
--
CLUELESSNESS:
There are No Stupid Questions,
But There Are a LOT of Inquisitive Idiots
I've just checked this in because the disassembler has come adrift
from the assembler. I don't know if this is the right fix, because
it feels like a hack, but it seems to work well enough for me to
debug some failing tests.
Index: disassemble.pl
==
On Fri, Sep 21, 2001 at 03:52:52PM -0400, Gregor N. Purdy wrote:
> OK. I'm tinkering with this a bit, but I've tripped over what appears to
> be a bug somewhere in the PackFile::* classes.
You too, eh? I think it would be a VERY good idea to have the configure
process spit out a module containin
I've just been fiddling around with the assembler and disassembler,
so that they use Gregor's PackFile modules. While this now means
that assembly and disassembly will Just Work seamlessly when we
change types and pack formats, it does look like I've broken something
on Tru64, or at least, expose
On Sat, Sep 22, 2001 at 03:56:09PM +0100, Simon Cozens wrote:
> I'm looking into it now.
Fixed. Parrot is now as broken as it was on Tru64 before I
started messing with it, but now it will also Do The Right
Thing when you change the internal types.
--
Asynchronous inputs are at the roo
On Sat, Sep 22, 2001 at 04:37:00PM +0100, Simon Cozens wrote:
> Fixed. Parrot is now as broken as it was on Tru64 before I
> started messing with it
And now I know why! The branch-fixup section of the assembler's busted:
0030: branch_ic 0040
003c: print_sc [
On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
> And now I know why! The branch-fixup section of the assembler's busted:
No, that wasn't it. This is it:
opcode_t *ne_nc_ic(opcode_t cur_opcode[], struct Parrot_Interp *interpreter) {
IV return_offset = 5;
if (NUM_R
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
> or is there a saner way to do it?
There is, and I've done it. (removed an assumption in process_opfunc.pl)
Jarkko, please resync; I think you'll find only one test now fails.
Unfortunately, I do not have the slightest
On Sat, Sep 22, 2001 at 05:31:50PM +0100, Simon Cozens wrote:
> Unfortunately, I do not have the slightest idea why that is failing...
That's failing because the test is way bogus. Mattia, consider yourself
slapped - 4.61168601842739e+18 is only 4611686018427389952.00 on broken
p
On Sat, Sep 22, 2001 at 04:33:31PM +0200, Mattia Barbon wrote:
> Before I spam everyone with this,
> is someone interested in it
I'm *very* interested in it.
> and if so,
> should I continue sending it to perl6-internals,
> or is is preferable a different ML?
For now, let's have them here. We c
On Fri, Sep 21, 2001 at 02:51:02PM -0400, Andy Dougherty wrote:
> I fear some sort of alignment or sizeof() issue is at work, and I'd hate
> to see whatever problems exist so far get widely propagated into other
> pieces of the source.
I've just cleaned up all the alignment and sizeof() issues fr
On Sat, Sep 22, 2001 at 05:45:12PM +0100, Simon Cozens wrote:
> Parrot's tests now run successfully on Tru64 and Linux.
That is, Linux x86. Linux Alpha just compiled successfully too.
--
sub UNIVERSAL::AUTOLOAD{ $UNIVERSAL::AUTOLOAD =~ s/::/ /; print
"$UNIVERSAL::AUTOLOAD &q
On Sat, Sep 22, 2001 at 09:05:53PM +0100, Leon Brocard wrote:
> Attached patch makes sure you don't try and use register numbers over
> 31. That is, this patch allows registers I0-I31 and anything else gets
> a: Error (foo.pasm:0): Register 32 out of range (should be 0-31) in 'set_i_ic'
Applied,
On Sun, Sep 23, 2001 at 12:27:53AM +0200, Mattia Barbon wrote:
> [parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
> ccflags="-O3 -Iinclude" --define iv=long --define nv=double
> [parrot]$ make
> [parrot]$ for i in t/op/number*.pbc ; do ./test_prog $i; done
Whoa - did you re-assemb
I've found the bug on Linux Sparc; This is either a bug in Parrot, or a bug in
Perl, and I can't tell which.
On this machine, NVs are doubles; their pack_type is 'd', which is as it should
be. So, a number (2.0) is inserted into the bytecode stream with pack('d', 2.0)
However, when I try derefer
On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
> unaligned access
Bother. It is as I feared.
Dan, we need to do something about this. The choices are: put floats into the
constant section, or ensure instructions are assigned on an appropriate
boundary. I can see pros and con
On Sat, Sep 22, 2001 at 04:41:28PM -0700, Benjamin Stuhl wrote:
> at load time. Yes, it's slow and hackish, but strings are
> the only *portable* format for floating-point numbers
I thought (although I might have conveniently forgotten the other
side of the argument:) that we weren't that concern
On Sat, Sep 22, 2001 at 07:12:05PM -0400, Michael G Schwern wrote:
> Compaq has a program called "Testdrive" where they offer free accounts
> on a VERY wide range of machines & OS's. Tru64, Caldera, Debian,
> Redhat, Kondara, OpenVMS, Mandrake, SuSE, Turbo, NetBSD, FreeBSD,
> Beowulf, iPAQ on Alp
On Sun, Sep 23, 2001 at 02:13:47AM -0400, Ken Fox wrote:
> Anybody know what the enter/exit scope percentage is?
Naturally, it depends on the code. 10% is a reasonable estimate.
Don't take my word for it. Add this to the top of any program:
use B::Utils;
CHECK {
B::minus_c;
B::Utils::wa
On Sun, Sep 23, 2001 at 04:03:59PM +0200, Mattia Barbon wrote:
> with floats. Tomorrow at the university
> I can debug the problem
Cool; thanks for this. Can you add a row to your smoke configuration
which does *not* change the default type sizes?
Simon
--
"Darkly hinting of head h
On Sun, Sep 23, 2001 at 08:42:51PM -0700, Wizard wrote:
> Is Parrot to have a strings db for error and UI strings (i18n)?
Parrot should not be outputting that many errors or UI strings. However,
those that it does should go through I18N, yes.
> If so, it should probably go on the TODO list (the
http://astray.com/mandlebrot.pasm
Leon, you're a sick, sick man.
--
TorgoX: you're rapidly learning, I see, that XML is a fucking
piece of festering shit which has no more justification for walking
God's clean earth than a dung beetle with diarrhoea.
On Sun, Sep 23, 2001 at 06:59:48PM -0700, Dave Storrs wrote:
> I.e., what is fair game to be worked on
* Documentation
* Tests
* Portability fixes
> and what is a "hold off for now?"
* Everything else
--
I see ADA as a larger threat than communism at this point in time -- Ted Holden
On Sun, Sep 23, 2001 at 10:05:20PM -0400, Steven W McDougall wrote:
> This patch makes them go away.
And it doesn't appear to break anything else in the process. Thanks,
applied!
Just out of interest, what are the tests looking like on IRIX?
> -opcode_t *(*(*opcode_funcs)[2048])(); /* Opcod
On Mon, Sep 24, 2001 at 09:16:10AM -0400, Andy Dougherty wrote:
> I'm afraid I'll have very little time this week to track this down myself.
It's OK; I've found myself a SPARC machine and I'm looking into it.
--
Calm down, it's *only* ones and zeroes.
stants so that the NVs can be read off.
Simon
--
"Language shapes the way we think, and determines what we can think about."
-- B. L. Whorf
On Mon, Sep 24, 2001 at 03:14:19PM +0100, Leon Brocard wrote:
> While we're at it: Simon, what do we need to have ready before
> we release the next version?
OK, here's the release roadmap for the near future:
0.0.2 will be released when all tests pass on the core platform
On Mon, Sep 24, 2001 at 09:16:34AM -0500, Gibbs Tanton - tgibbs wrote:
> assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've
> done a cvs update -dP and it doesn't get added...what happend to this file?
You need to rerun Configure.
--
[Bastille Linux] Of course, if we cons
On Sat, Sep 22, 2001 at 11:56:26PM +0100, Alex Gough wrote:
> I wrote some tests today...
Thanks, applied.
--
A year spent in artificial intelligence is enough to make one believe in God.
On Mon, Sep 24, 2001 at 03:16:47PM -0400, Steven W McDougall wrote:
> t/op/number.t 255 6528023 144 626.09% 1-23
> 6/74 subtests failed
Looks like Test::Harness has no brains either.
--
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Atheists prefe
On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
> Tru64
> make ok / test fails
Can I have some more data on this? Works perfectly here.
--
To downgrade the human mind is bad theology.
- C. K. Chesterton
When tests fail for Really Bad reasons, they tend to do something like this:
Got: '
'
Expected: '
ok 1
...
'
It'd be really nice if we could intercept that and give more detail on why
the test failed. Did the assembler compile to a PBC ok? Did the interpreter
segfault? (This is what usually happ
on's
patch applied. In fact, Brent and Tanton should work together so that
Makefile.in is hacked up and not Makefile.
Good luck, team! :)
Simon
On Tue, Sep 25, 2001 at 12:45:02AM +0100, Alex Gough wrote:
> noop didn't have a test, ironic yes, but imagine the shame if it didn't work.
If noop does anything that could remotely be called work, it's broken. :)
Thanks, applied.
--
"The Amiga is the only personal computer where you can run a
On Wed, Sep 26, 2001 at 12:05:49AM +0200, Mattia Barbon wrote:
> O O
> O O nv=double
> O O nv=\"long double\"
> O O iv=int
> O O iv=int nv=double
> O O iv=int nv=\"long double\"
> O O iv=long
> O O iv=long nv=double
> O O iv=long nv=\"long double\"
Weird. That probably shouldn't happen.
On Tue, Sep 25, 2001 at 04:24:53PM -0700, Damien Neil wrote:
> I'm interested in looking at the bytecode loader, if nobody else
> has intentions there.
I think that's exactly what needs work, and one of the things Gregor
is looking at. Here's how it goes.
Before 0.0.2 is released, we need to pa
using packfile.[hc]
> for its work (I posted a patch earlier today).
> I'm just waiting for the thumbs-up from Simon and Dan before committing
> that increment
I'll look at it in the morning.
> Dan? Simon? Is Inline::C ok?
>From my point of view, I'm afraid I'
On Tue, Sep 25, 2001 at 07:51:22PM -0400, Gregor N. Purdy wrote:
> Is there hope that 0.0.2 could be out by the end of the week if I get
> the tasks assiged to me done RSN?
Once we've got NVs into the constant table, we can ensure they're aligned
nicely, and all the problems we're seeing on Sparc
On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
Just the one? I'm getting six of the damned things.
--
Mohandas K. Gandhi often changed his mind publicly. An aide once asked him
how he could so
Holy crap.
- Forwarded message from Andrew Kuchling <[EMAIL PROTECTED]> -
From: Andrew Kuchling <[EMAIL PROTECTED]>
Subject: [Python-Dev] Crude Python->Parrot compiler
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
X-Beenthere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.6 (101270)
Over
On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
> Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS is designed for a
> 32 bit system. It needs to be changed in the Configure.pl script to be
> 0xf000 for 64 bit systems. With that changed it works fine.
On Wed, Sep 26, 2001 at 09:46:42AM -0700, Brent Dax wrote:
> Now, how do I figure out if we're on a 64-bit system? :^)
$Config{ptrsize} == 8;
--
Some people claim that the UNIX learning curve is steep, but at least you
only have to climb it once.
On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> Don't bother. Make the constant be ~0xfff. :)
Oh yeah. *blush*.
--
It would be different if I had an actual ambition to be a corporate pitbull
and be the righteous, noble paperwork warrior tirelessly fighting for the
future vision
On Wed, Sep 26, 2001 at 06:15:02PM +0100, Simon Cozens wrote:
> On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> > Don't bother. Make the constant be ~0xfff. :)
>
> Oh yeah. *blush*.
All tests successful, 5 subtests skipped.
Yeah!
--
Writing software is more fun than working.
On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy wrote:
> I've just committed the changes I posted a few days back that prepare
> for putting NVs in the const_table. Stay tuned for more, but here's
> the bullets for this commit:
These are pretty huge changes. Can I get some status report
Sorry. It's still throwing tests on Sparc. Tracking it down now.
--
So what if I have a fertile brain? Fertilizer happens.
-- Larry Wall in <[EMAIL PROTECTED]>
On Sun, Sep 30, 2001 at 11:31:21AM -0400, Gregor N. Purdy wrote:
> Gibbs had a Solaris success (I assumed Sparc). If you've got a
> different setup, I'd suggest looking at packfile.c in function
> PackFile_Constant_unpack_number(). Maybe we need to use memcopy
> instead of an assign (see the TODO
On Sun, Sep 30, 2001 at 11:25:04AM -0400, Gregor N. Purdy wrote:
> * Solaris (Sparc)
This was failing here until I made the following change:
PackFile_Constant_unpack_number(struct PackFile_Constant * self, char * packed, IV
packed_size) {
char * cursor;
NV value;
NV * align
On Sun, Sep 30, 2001 at 12:57:53PM -0700, Brent Dax wrote:
> I mentioned this idea before, and I've managed to implement a bit of it.
VERY GOOD WORK!
> That isn't quite valid Parrot bytecode, because of the concat. Concat
> is currently documented to take only two arguments.
This is because co
On Sun, Sep 30, 2001 at 01:37:44PM -0700, Hong Zhang wrote:
> The memcpy() can handle alignment nicely.
Not always. I tried. :(
--
"How should I know if it works? That's what beta testers are for. I only
coded it."
(Attributed to Linus Torvalds, somewhere in a posting)
On Sun, Sep 30, 2001 at 03:36:53PM -0700, Nicholas Knight wrote:
> A couple hours ago (3:34PM PDT), someone commited a new version of the
> MANIFEST file to the Parrot CVS. This file contains a file name that is
> missing, Parrot/String.pm, on line 11. Running "perl Configure.pl"
> fails as a r
On Sun, Sep 30, 2001 at 07:07:34PM -0500, Gibbs Tanton - tgibbs wrote:
> mem_sys_memcopy( &value, cursor, sizeof(NV) )
I'm being stupid. Of course that ought to work.
(And it does, everywhere it matters.)
> does the sizeof(IV) have something to do with it?
It's to do with me being confused
On Sun, Sep 30, 2001 at 11:37:37PM -0400, Jason Gloudon wrote:
> Here is a patch for macros for accessing constants from ops. This uses
> (INT|STR|NUM)_PCONST(i) for the relevant types. Best to avoid filling opcode
> definitions with manual structure dereferences.
Nice idea, but I'd *much* rathe
On Mon, Oct 01, 2001 at 07:20:56AM -0500, Gibbs Tanton - tgibbs wrote:
> Casting to IV doesn't actually hurt anything (unless there is an alignment
> issue); however, casting to char* is the more idiomatic way of doing it.
> I'll commit this unless Simon says he is going t
On Mon, Oct 01, 2001 at 10:23:11AM -0400, Jason Gloudon wrote:
> What about the current macros for NUM_REG etc ?
I'd probably rip 'em out too. Stops people accidentally hand hacking the .c file
instead of the .ops file and then losing all their changes on rebuild. Not
that I've ever done that tri
On Sat, Sep 29, 2001 at 12:08:20AM -0700, Josh Wilmes wrote:
> Here's a fixed version of that patch I sent a while back:
Thanks, applied.
--
A formal parsing algorithm should not always be used.
-- D. Gries
On Sun, Sep 16, 2001 at 01:44:12PM -0400, Michael Fischer wrote:
> Small hack to keep process_opfunc.pl from generating
> extra return() statements.
Thanks, applied.
--
Hanlon's Razor:
Never attribute to malice that which is adequately explained
by stupidity.
On Mon, Oct 01, 2001 at 04:22:30PM -0400, Jason Gloudon wrote:
> It breaks manual ops like eq_i_ic since the generated code can return without
>returning a value.
Yeah, I just noticed that myself. :) Retracting.
--
Rule 3: If the character is comprised of a container without another radical,
On Mon, Oct 01, 2001 at 06:10:55PM -0400, Michael Fischer wrote:
> Its also at least 2 weeks old, and obsoleted/made incompatible
> by lots of other stuff during that time, including opcode switch()
> stuff I'd sent to other commiters (presumably unused).
The opcode switch stuff I can't use in it
On Tue, Oct 02, 2001 at 02:18:09AM -0700, Brent Dax wrote:
> linux--debugging --defaults --define nv=\"long double\"
Thanks, looking at this. From here, it seems to be throwing
tests left, right and center.
--
Sendmail may be safely run set-user-id to root.
-- Eric Allma
On Tue, Oct 02, 2001 at 10:23:22AM +0100, Simon Cozens wrote:
> On Tue, Oct 02, 2001 at 02:18:09AM -0700, Brent Dax wrote:
> > linux--debugging --defaults --define nv=\"long double\"
>
> Thanks, looking at this. From here, it seems to be throwing
> tests left,
On Tue, Oct 02, 2001 at 07:36:39AM -0400, Jason Gloudon wrote:
> This patch removes the preprocessor macros for register access. These are now
> substituted in basic_opcodes.ops by process_opfunc. The patch also adds
> substitution for NUM_CONST(), STR_CONST(), INT_CONST() for constant access in
>
On Tue, Oct 02, 2001 at 08:47:57AM -0400, Andy Dougherty wrote:
> I've just re-synced and can poke around a bit today, but that's one place
> I'd start looking.
I'm afraid you're going to have to re-resync. Big change coming up in a
few minutes.
--
"I find that anthropomorphism really doesn't h
Has happened.
IV -> INTVAL
NV -> FLOATVAL
Nobody complained when I issued a head's-up last week, so you've only got
yourself to blame if you're not OK with this. :)
--
"Do not meddle in the affairs of cats, for they are subtle and will piss on
your computer." --Bruce Graham
On Wed, Oct 03, 2001 at 08:26:07AM -0400, Gregor N. Purdy wrote:
> +IV byte_code_size;
> +char * byte_code;
> +char * byte_code_end;
> +char * cursor;
> +IV * iv_ptr;
> +NV * nv_ptr;
What's an IV?
--
"Don't worry about people stealing your ideas. If your ideas
On Wed, Oct 03, 2001 at 10:45:08AM -0400, Bryan C. Warnock wrote:
> while (pc >= code_start && pc < code_end && *pc) {
> do {
> x = z->opcode_funcs; \
> y = x[*w]; \
>w = (y)(w,z); \
> } while (0);
> }
>
> to
>
> x = z->opcode_funcs;
The optimizer should hoist
Any objections to a release today? How's Cygwin and Win32 looking?
--
> I'm a person, not a piece of property.
Happily, I'm both!
- Lionel and Stephen Harris.
On Wed, Oct 03, 2001 at 03:55:55PM +0100, Simon Cozens wrote:
> Any objections to a release today? How's Cygwin and Win32 looking?
FWIW, I've just successfully built Parrot on Linux x86, Linux Sparc,
Linux IA64, Tru64, Linux Alpha, FreeBSD Alpha, and FreeBSD x86.
I'm happy.
On Wed, Oct 03, 2001 at 11:44:25AM -0400, Andy Dougherty wrote:
> It's not a core platform, but Linux/Sparc (intvalsize=8) is still not
> very happy:
OK; I'll have to check that out. The Sparc I have here has intvalsize=4
by default.
--
"Contrariwise," continued Tweedledee, "if it was so, it mi
On Wed, Oct 03, 2001 at 04:54:41PM +0100, Alex Gough wrote:
> Chopn is broken for n < 0, here a fix and tests.
Thanks, applied. (with a tiny style correction)
--
You're never alone with a news spool.
On Wed, Oct 03, 2001 at 05:52:19PM +0200, H. Merijn Brand wrote:
> HP-UX 11.00 w/ HP ANSI C
> -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE
>-D_FILE_OFFSET_BITS=64 -I./include
Thanks. Also:
$ uname -a
SunOS neptune 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-5_10
Ho
)
> Fortunately, perl5.7.x's Configure already does some of this
> for us.
Paging Robin Barker, paging Robin Barker.
Simon
--
$\=" ";@a=qw/hacker, Perl another Just/;sub TIESCALAR{bless[]};tie $a,$a;
*STORE=*FETCH=sub{print pop @a};$_++for$a,$a;
On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote:
> Win2K non-Cygwin is looking a little sick to its stomach:
Dammit. There had to be a show-stopper, didn't there?
--
The Blit is a nice terminal, but it runs emacs.
OK, let's try and clear this up.
On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote:
> # got: 'Seem to have negative Nx
> not ok
> '
> # expected: 'Seem to have negative Nx
> Seem to have positive Nx after pop
> '
Don't know what's going on here.
> t/op/string.NOK 4#
On Wed, Oct 03, 2001 at 12:53:40PM -0400, Gregor N. Purdy wrote:
> I'd like to have a working macro facility in the assembler for 0.0.2,
> please.
Don't worry, Windows being broken has bought you some time...
--
"In space 'cat scream.au | tee /dev/null > /dev/audio'..."
- Ben, in the monastery
On Wed, Oct 03, 2001 at 05:51:14PM +0100, Simon Cozens wrote:
> > # got: 'Seem to have negative Nx
> > not ok
> > # expected: 'Seem to have negative Nx
> > Seem to have positive Nx after pop
So pop_n is broken on Win32. Did you see any compiler warn
Botheration, I forgot all about this. How's it coming on?
--
IBM:
It may be slow, but it's hard to use.
On Wed, Oct 03, 2001 at 01:52:05PM -0400, Dan Sugalski wrote:
> If we don't build on VMS it's not a show-stopper for 0.02.
I think it is. There's not much point having a core platforms
list if we selectively ignore it. :(
--
* DrForr digs around for a fresh IV drip bag and proceeds to hook up.
On Wed, Oct 03, 2001 at 01:55:39PM -0400, Dan Sugalski wrote:
> If you want to wait, that's fine. I don't think I'm going to get untangled
> for another day or three, though.
Waiting might also help to shake out whatever's wrong with Win2K. Maybe
it's just Brent's system being funny. (And I'd tr
On Wed, Oct 03, 2001 at 12:08:54PM -0700, Benjamin Stuhl wrote:
> # got: 'failure
> '
What no debugging print output?
--
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise.
-- Larry Wall
On Wed, Oct 03, 2001 at 01:18:04PM -0700, Brent Dax wrote:
> foreach(grep {/pattern/} keys %Config) {
> blah blah blah
>
> with:
>
> while($_=each %Config) {
> next unless /pattern/;
> blah blah blah
Better, but it doesn't appear to ever *en
On Thu, Oct 04, 2001 at 02:45:31PM +0100, Simon Cozens wrote:
> Oh dear.
Even if I hack it wildly:
Alright, now I'm gonna check some stuff by compiling and running
a small C program. This could take a bit...
Use of uninitialized value at configure.pl line 140.
CC/DECC /float=ieee
On Fri, Oct 05, 2001 at 01:46:44AM -0700, Ask Bjoern Hansen wrote:
> (uh, and of course: I would move them directly in the cvs repository
> as to preserve the revision history properly).
Go for it.
--
It can be hard to tell an English bigot from a monoglot with an
inferiority complex, but one c
On Sat, Oct 06, 2001 at 08:19:16AM -0400, Michael Fischer wrote:
> Why were they there?
Because 'l!' does exactly the right thing on Perl version 5.6.0 and
above, and 'l' is not guaranteed to do exactly the right thing.
--
It starts like fascination, it ends up like a trance
You've gotta use
201 - 300 of 1107 matches
Mail list logo
