Will Coleda (via RT) wrote:
Trying to patch punie, I get to a point with the following:
wcoleda$ cat foo.pir
.sub main :main
$P1 = compreg "PAST"
$P2 = $P1("Parrot_AST(Py_Module(Stmts(Py_Print(Const(1)")
$P2()
.end
wcoleda$ ../../parrot foo.pir
src/packfile.c:2314: failed assertion
Will Coleda via RT wrote:
[leo - Tue Nov 08 02:17:18 2005]:
Will Coleda (via RT) wrote:
wcoleda$ cat foo.pir
.sub main :main
$P1 = compreg "PAST"
$P2 = $P1("Parrot_AST(Py_Module(Stmts(Py_Print(Const(1)")
$P2()
.end
The assertion error is gone, but I now get a segfault running this
Nick Glencross (via RT) wrote:
This patch closes filehandles which are being leaked by imcc.
Thanks, applied - r9845.
leo
On Nov 8, 2005, at 19:56, Will Coleda wrote:
Anyone care to suggest some updated text for "Where we are?".
I'm currently in Herrnbaumgarten/Austria ;-)
But anyway, the two references to the outdated and presumabely
non-functional P6C should be replaced with more recent info towards PGE
or
- skip non-fatals like unit stack memory spotted by valgrind inside GC
uninitialised
leo
On Nov 9, 2005, at 14:55, Roger Browne wrote:
The 'find_type' opcode seems to return a positive integer for a PMC or
ParrotObject, and a negative integer for a Parrot datatype such as
"longlong".
... and 0 for unknown types.
Yep. If you are unsure, if your name is a class name, test for the
Joshua Hoblitt wrote:
I've taken a look at using Module::Pluggable to register configure
steps. The simplest way to do this is to let Module::Pluggable search
through the ./config directory. This requires renaming all of the .pl
configure files to .pm because of hardwired assumptions in
Module:
string_chopn was badly broken in several ways:
- calculated wrong string.bufused for e.g. utf8
- tried to modfiy COW or external strings in place
This is fixed now, but string_chopn needs and extra argument 'in_place'
to work correctly.
leo
I'm currently going through the various string functions and make them
usable for all string encdodings we have. It's not finished yet, but a
lot already works.
We have:
charsets: binary, ascii, iso-8859-1, unicode
encodings: fixed_8, utf8, utf16, ucs2
utf16 is a bit special, as it falls i
Roger Browne wrote:
Is it documented anywhere what are the legal names for a PMC?
I tried to use the name "AMBER::BOOLEAN" but pmc2c objects with:
bad block open: ::BOOLEAN ...
at /home/install/parrot/svn/build_tools/pmc2c.pl line 355,
To me it seems that the created C code is the limit
With ICU installed we have now a rather complete support for unicode
string manipulation (byte, codepoint levels).
Still todo is string_bitwise_{or,and,xor}.
What should happen, if charsets, or encondings don't match, if encoding
is utf8 or utf16/ucs2, ...
I think there are basically two opt
Jerry Gay via RT wrote:
please take another look at this ticket, as the new scheme is now in
effect.
The bug is more unlikely now but else nothing has changed.
~jerry
leo
On Nov 12, 2005, at 15:37, Will Coleda wrote:
A visitor on #parrot just asked if we had a fink build (which we
don't). Before I bother the fink folks directly, is there anyone
listening here who can help us put a fink build together?
You forgot to mention that parrot is already debianzed (
On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
{ First, let's have a little applause for Leo for implementing the new
lexical scheme in, what, a week? He says it was only a half-day's
work, too. Nice work, dude! }
It was just half a day. The rest of the week was spent on unicode
improvem
:outer("foo") now basically works, there is also a new Sub method
C.
There is one limitation though: the subroutine referenced by :outer must
be already compiled, that is: it must be in the same sourcefile [1] and
it's source code has to appear before the sub referencing it [2].
[1] can for
... which has bison 1.28 installed (not quite state of the art)
*) tried apt-cache search bison
- most recent package reported is 1.35 - that's ancient too
- canceled
*) installed bison 2.1 into ~/bison from source (actually
--prefix=/Users/lt/bison)
- works despite of slightly older
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
Hi,
.hll_debug file "something.pl"
.hll_debug line 1
Just
#line 123
#line 789 "file.foo"
looks simpler and well known to me - the latter is already parsed. But
actually making it work is more important for me.
Either an integer
On Nov 14, 2005, at 21:06, Nick Glencross wrote:
While nesting one begin/end line number directly inside another
doesn't make much sense, my reasoning for this is for inlining of code
where you nest a new filename/line/column and then these are popped to
get back to the original calling locat
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
* I'm thinking of a PIR syntax along the lines of this:-
The discussion goes forth and back, like all other discussion we
already had WRT syntax, months and years ago.
I'd much more prefer that a compiler (amber anyone ;) just emits PIR
On Nov 15, 2005, at 0:07, Jonathan Worthington wrote:
What's the fascination with overloading comment syntax?
Because a compiler can emit it right now w/o any change to Parrot.
Jonathan
leo
On Nov 15, 2005, at 4:28, Chip Salzenberg wrote:
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:
OK, call frame as PMC looks like a non-starter. Consider it rescinded.
Autrijus mentioned on #parrot that we'd need weak pointers at some
time. Then we can recon
On Nov 15, 2005, at 10:04, Brent 'Dax' Royal-Gordon wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Because a compiler can emit it right now w/o any change to Parrot.
That's an advantage for the week it takes to implement the feature.
For the remaining age of t
Tonight on #parrot:
03:15 <@mdiep> meaning that imcc doesn't know it's being feed utf8
instead of ascii
03:16 <@Coke> mdiep: B***it. it knows the encoding of the string.
*) Parrot's compilers take plain old C-strings and don't know anything
about the charset/encoding of the string - but read
On Nov 15, 2005, at 17:24, The Perl 6 Summarizer wrote:
The Perl 6 Summary for the fortnight ending 2005-11-13
"string_bitwise_*"
Leo, it seems to boil down to a choice between throwing an
exception or
simply mashing everything together and marking the 'resulting bit
mess'
Nick Glencross wrote:
coroutine_3.pasm seems to have some problems with scratchpads, but I
don't know whether the problem is with parrot or the test.
==15739== Thread 1:
==15739== Invalid write of size 1
Yep. I have seen the overwrite too with scratchpads. But as scratchpads
will be removed
On Nov 16, 2005, at 19:27, Erik Paulson wrote:
Hello,
As a class project, we're looking at transactional memory, and one of
things
we'd like to try and do is add some basic TM support to Parrot.
Cool.
To start out with, we'd add three new opcodes - one to begin, end, and
abort the curre
Erik Paulson wrote:
Some basic questions: is there a notion of "current time" in Parrot, like
a cycle counter or anything?
It would be rather easy to add a cycle counter. I was thinking of:
- new field interpreter->cycle_counter
- increment it on each opcode executed that involves PMC argumen
Jonathan Worthington (via RT) wrote:
Don't have time to track this down myself right now, but if you do
parrot -o it.pbc it.pir
With the attached, it segfaults.
Thanks, fixed - r10089
leo
On Nov 20, 2005, at 22:09, Joshua Hoblitt wrote:
I've like to nominate Jerry for an entry in RESPONSIBLE_PARTIES as the
test suite maintainer. Thanks for all your work Jerry.
Any objections?
Not at all - more the opposite ;-)
-J
leo
Below are two cases of inner subs in Perl5 and Python. The first
(do_add3) is a plain nested subroutine, which is in the call chain. The
second (mk_add3) uses a closure. perl5 can't deal with case 1 properly
and warns.
The question is: should Parrot cover case 1 too with :outer and it's
defau
dynclasses/dynlexpad.pmc provides (or should eventually provide) a more
dynamic lexpad (similar to the deprecated scratchpad.pmc). It's not
finished yet, it doesn't consult LexInfo for static lexicals yet.
Before working more on it, I'd like to know from HLL authors, what they
need.
Currentl
On Nov 22, 2005, at 18:32, Chip Salzenberg wrote:
OTOH, that same case in Perl 6 is a normal closure and is supported
with
the default LexPad:
Ok. I'll change implementation accordingly. Below is the full code of
case 1 / outer.pir
leo
.pragma n_operators 1 # add creates new PMC
On Nov 22, 2005, at 18:50, Roger Browne wrote:
Leopold Toetsch wrote:
.HLL_map .LexPad -> .DynLexPad # (2)
Why not use "," instead of "->"? It would be one less special-case for
the PIR programmer to remember.
No problem. If folks prefer a comma I&#
On Nov 22, 2005, at 19:52, Chip Salzenberg wrote:
On Tue, Nov 22, 2005 at 05:50:39PM +, Roger Browne wrote:
Why not use "," instead of "->"?
Indeed. We shouldn't introduce "->" at this point, when we already
use the perfectly serviceable comma for analogous cases.
Done, r10140.
leo
On Nov 22, 2005, at 1:40, Matt Fowles wrote:
Call Frame Access
Chip began to pontificate about how one should access call frames.
Chip
suggested using a PMC, but Leo thought that would be too slow.
No, not really. It'll be slower, yes. But my argument was: whenever you
start int
On Nov 23, 2005, at 4:42, Will Coleda wrote:
I'd like to provide an easy way to provide this mapping for language
developers so the users of the language don't have to remember to add
the second line whenever they use, e.g. Tcl.
Whenever some code is using e.g. Tcl, a library is loaded that
On Nov 23, 2005, at 6:13, Josh Isom wrote:
When I first installed parrot, curses worked with it, but it fails to
work
anymore for me, either under darwin or freebsd. On darwin, it clears
the
screen, and can only read "assertation failed" before it clears and
dies,
so I can't see diagnostics
On Nov 23, 2005, at 3:06, chromatic wrote:
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote:
But my argument was: whenever you
start introspecting a call frame, by almost whatever means, this will
keep the call frame alive[1] (see Continuation or Closure). That is:
timely destruction
Roger Browne wrote:
.sub add3 :method :outer('do_add3')#(4)
.param pmc arg
$P0 = n_add arg, 3 #(5)
.return($P0)
.end
This segfaults at #(3).
Actually at #(5)
- replace line #(5) by "$P0 = n_neg arg" (the significance
The reason was lexical lookuo inside M
Roger Browne wrote:
A bigger problem will occur for any HLL that has no PMCs of its own, yet
wishes to use DynLexPad. How to specify that?
As coke writes this is in the intial posting of this thread, but he has
cited only half ot the show. Here is all again:
SYNOPSIS
.sub _load :immediat
On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
On Wed, Nov 23, 2005 at 03:14:40PM -, [EMAIL PROTECTED] wrote:
implement Sub.get_caller() method; test
You keep confusing static and dynamic call information.
Not confusing actually, maybe abusing the static sub structure by
adding a d
On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
You keep confusing static and dynamic call information.
While at static objects like subroutine PMCs - there is some code
around that is setting properties on .Sub objects.
$ find . -name '*.imc' -o -name '*.pir' | xargs grep -w setprop
At
jerry gay (via RT) wrote:
test 502 causes parrot to eat all memory and use all cpu (on win32 anyway.)
since i've added a special env var to support the running of a single
test in this test file, it can be run in isolation like:
set TEST_P5RX=502
prove t/compilers/pge/p5regexp/p5rx_1.pir
b
I'm currently fixing #37590 and removed tons of code from imcc/pbc.c.
The changes are causing a more strict error checking WRT label usage
and a slight restriction WRT labels in PASM code:
.pcc_sub foo:
...
branch foo
is now illegal. In practice there is probably always a get_params after
Likely due to the stricter label checking we have these test failures
now:
Failed Test Stat Wstat Total Fail Failed List
of Failed
---
t/compilers/pge/p5regexp/p5rx.t 2 512 8002
On Nov 25, 2005, at 2:08, Patrick R. Michaud wrote:
Now fixed in r10176, thanks!
Wow, that is fast, thank you.
Pm
leo
The last (and never done correctly) relict of old calling conventions...
Technically an excpetion is kind of an object with some info (TODO) and
the exception handler is a (limited) continuation:
pmclass Exception_Handler extends Continuation ... # see classes/
Throwing an exception is
On Nov 26, 2005, at 22:16, chromatic wrote:
Hi all,
Here's a first shot at Test::More in pure PIR. It only supports
plan(),
ok(), and is() (for integers, floats, strings, and PMCs) right now. If
everyone's reasonably happy, I'll check it in.
chromatic please make that sentence: 'If no on
The whole scratchpad is doomed and will be scratched RSN (see pdd20
instead). A patch with immanent changes is at
http://perlcabal.org/~lt/pad.diff
but the patch doesn't properly reflect deleted files - if you like to
experiment, please svn rm the deleted files:
D src/lexical.c
D
On Nov 28, 2005, at 22:37, Chip Salzenberg wrote:
PS: I'd forgotten the lex opcodes used to follow the *call stack*.
My unholy $DEITY, they were even more broken than I remembered.
Yes. And have supported hacks that were far beyond anything dubbed as
damian-ish (pdd20).
Re: tcl - it's
On Nov 29, 2005, at 1:45, jerry gay wrote:
the parrot directory structure is large and a bit disorganized.
let me give you some examples:
* build_tools/, util/, and tools/*/ each contain utility perl
scripts. these should be grouped together under tools/, which
already contains subdirectori
jerry gay wrote:
+---t
| +---compilers
| | +---imcc # moved from imcc/t/
| | |
This doesn't really work for me. imcc/t* used to test some general
parsing features, code generation and register allocation. Therefore it
should run early in the tests.
What about
Leopold Toetsch wrote:
The whole scratchpad is doomed and will be scratched RSN (see pdd20
instead).
Committed as r10240.
All tests are passing on linux/x86 and linux-64/amd64.
Please make realclean ...
leo
Chip Salzenberg wrote:
On Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
catch_label:
get_results "(...)", Pexcept, Smessage, ... # whatever
This part is now implemented (r10241). (Funnily it did work immediately :)
Currently exactly these 2 arguments
Will Coleda wrote:
On Nov 29, 2005, at 8:38 AM, Leopold Toetsch wrote:
handler:
get_results "(0,0)", P0, S0
Currently, partcl stores extra information in P5[9] - Would it be
available as P0[9] in your example? (If so, is the message still
available as P0[0] ?
Sur
Leopold Toetsch wrote:
Syntactic sugar, ...
Done - r10243. Again exactly 2 arguments are supported for now:
handler:
.local pmc e
.local string mess
.get_results (e, mess)
Variable decls after the handler label aren't instructions and therefore ok.
See a
On Nov 25, 2005, at 23:45, Leopold Toetsch wrote:
The last (and never done correctly) relict of old calling
conventions...
... is gone now. Please consult docs/compiler_faq.pod or this thread
for using get_results instead.
From r10257
Exception handler code: P5 is gone
The compat code
On Nov 29, 2005, at 21:36, Chip Salzenberg wrote:
I'm planning a flag day sometime in December. I'm also planning to
create a simple "handles most cases" translator.
That's all ok with me, but not without an automatic translator, that
"handles 99.99% cases". As the current syntax is clear,
Parrot didn't throw exceptions on param or result count mismatch until
now, and still doesn't. [1]
But, I have invented 2 more error flag bits [2], which can enable
stricter argument checking and the exception is catchable in the
subroutine itself now:
.include "errors.pasm"
errorson .P
Jonathan Worthington wrote:
Hi,
I seem to be touching a bug related to writing compiled code.
pir_comp = compreg "PIR"
pbc_out = pir_comp(gen_pir)
fh = open output
print fh, pbc_out
close fh
On the print line, I get this error:-
directory_pack segment 'BYTECODE_EVAL_1' used size 158 but repor
Jonathan Worthington wrote:
$ parrot -o breaks2.pbc breaks2.pir
$ parrot breaks2.pbc example.dll
directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160
Same answer as Jerry - works here on x86/linux.
Thanks,
Jonathan
leo
On Nov 30, 2005, at 18:04, Peter Sinnott wrote:
I was refering to the bug that said :
"Also label fixup handling is different so just don't compile
PIR files to PASM except for debugging"
That is a bug related to printing PIR -> PASM and compiling the output
(which is still avtive, but unch
On Nov 30, 2005, at 22:08, Chip Salzenberg wrote:
On Wed, Nov 30, 2005 at 02:39:58PM -0600, Patrick R. Michaud wrote:
At any rate, I found and fixed the two PGE subs that weren't declaring
their (unused) parameters. All p6rules tests now appear to pass in
r10278 with .PARROT_ERRORS_PARAM_COUN
On Nov 30, 2005, at 22:16, Chip Salzenberg wrote:
Say, I just noticed this:
On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
.sub foo
push_eh handler
get_params '(0)', $P0# no .params yet - sorry
I remember at one point that get_params had
On Dec 2, 2005, at 0:42, Allison Randal wrote:
I realize this is a side effect of the fact that method names are
actually strings, but it's an unfortunate result.
.sub main :main
newclass $P1, 'Thingy'
$P2 = new 'Thingy'
$P2.snark()
end
.end
.namespace [ "Thingy" ]
.sub sna
On Dec 2, 2005, at 10:50, François PERRAD wrote:
I try to update and test Lua PMC.
I take inspiration in code of Tcl and Amber.
It's OK for these 2 PMC :
pmclass LuaNumber hll Lua maps Float
pmclass LuaString hll Lua maps String
But for :
pmclass LuaBoolean hll Lua ma
The next release is due this weekend. I'll start release procedure at
Sun 4th, ~13:00 UTC.
The usual terms apply:
- no bigger changes to Parrot core, especially nothing that could break
the build or Parrot
- please test on all available platforms and 'make smoke' and/or update
PLATFORMS
- ple
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
[ Just a few notes, more to come. I've to read it some more times. ]
Naming Conventions
HLL Private Namespaces
HLLs should use a namespace with an underscore and the
lowercased
name of the HLL to store any private items.
On Dec 3, 2005, at 3:54, Bob Rogers wrote:
In rev 10317, parrot segfaults if the sub named in ":outer" is not
defined in the current compilation unit. The patch fixes the symptom,
and adds a test. (But the error message could be improved.)
Thanks, applied - r10320
leo
On Dec 3, 2005, at 4:31, Bob Rogers wrote:
The attached test case fails in rev 10317 as follows:
[EMAIL PROTECTED]> ./parrot -o lex-test-2-sub.pbc lex-test-2-sub.pir
[EMAIL PROTECTED]> ./parrot lex-test-2-main.pir
parrot: src/hash.c:243: hash_thaw: Assertion `info->extra_flags =
On Dec 2, 2005, at 19:59, Andy Dougherty (via RT) wrote:
Parrot_jit_emit_mov_mr_offs blib/lib/libparrot.a(jit.o)
Parrot_jit_emit_get_base_reg_no blib/lib/libparrot.a(jit.o)
Parrot_jit_emit_mov_mr_n_offs blib/lib/libparrot.a(jit.o)
Parrot_jit_emit_mov_rm_offs blib/lib/l
On Dec 3, 2005, at 14:45, Joshua Isom wrote:
:opt_flag preceeded by more then one :optional
current instr.: 'main' pc 52 (./aop.pir:93)
I don't see any function using :optional or :opt_flag in the program. I
can just repeat this answer regarding ncurses:
Please go through all the dlfunc
On Dec 2, 2005, at 19:44, Matt Diephouse wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
I'm missing the policy in this proposal, e.g. what is allowed to be a
top-level global, how are HLL namespaces organized. And of course:
where is the Parrot namespace for it's PMCs.
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
Typed Interface
add_sub($S0, $P0)
add_namespace($S0, $P0)
add_var($S0, $P0)
Which HLLs would use these interfaces? Can you please provide some
examples of HLLs with the usage of these interfaces.
Thanks,
leo
On Dec 3, 2005, at 20:15, Bob Rogers wrote:
Excellent; thank you -- and for the other fix especially. But now I
notice that this is what happens if you put the inner sub first:
Yes. That's what I've written in:
http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/
812c0e2a
On Dec 4, 2005, at 1:18, Bob Rogers wrote:
Sorry; I remember reading this now. Please accept the following small
patch to close the documentation gap.
NP and thanks - applied r10336
leo
On Dec 4, 2005, at 5:57, Matt Diephouse wrote:
Roger Browne <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
add_sub($S0, $P0)
add_namespace($S0, $P0)
add_var($S0, $P0)
Which HLLs would use these interfaces?
Maybe I'm missing the point, but I see these be
Please no further svn checkins, until the release announce is out.
Thanks,
leo
On behalf of the Parrot team I'm proud to announce another
major release of Parrot. More than 530 svn checkins and 1000
added tests by numerous folks bump up the version to 0.4.0.
I'd like to thank all involved people as well as our
sponsors for supporting us.
What is Parrot?
Parrot is a virtual
* svn ci is fine again - may the hacking continue
* a few 'make testr' (run test via .pbc) tests are broken, at least one
due to an expected compile error in the test, which then doesn't create
the test file of course. I didn't find the time[1] to look more closely
into other failures.
Thanks
This is an unordered collection of my thoughts towards a next release:
* namespaces: create a PDD based on Matt's document
* interfaces: start some brainstorming, what we might need in Parrot
core
* bytecode & library loading: needs rewriting and major cleanup
* config module cleanup: auto/jit.
On Dec 5, 2005, at 13:50, Roger Browne wrote:
I'm having some trouble accessing elements of multidimensional arrays
from PIR, and I'm not sure if what I want to do is buggy or
unimplemented, or if I'm simply doing it the wrong way.
$S0 = array[$P0; $P1] # [1]
Multi-dimensional keys
On Dec 5, 2005, at 8:03, David Dyck (via RT) wrote:
checked out todays version and found the following build error:
src/embed.c: In function `Parrot_readbc':
src/embed.c:373: `MAP_FAILED' undeclared (first use in this function)
Strange. Which linux and libc version is this?
Anyway, I've ch
On Dec 5, 2005, at 5:55, Matt Diephouse wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Of course, now that I think about it more, it's possible that nothing
else will be adding namespaces for Python.
Or: only python itself can create Python namespaces.
In which case I
On Dec 5, 2005, at 18:28, Andy Dougherty wrote:
On Sat, 3 Dec 2005, Leopold Toetsch via RT wrote:
Can you provide dummy subs for the _offs functions and put in a dummy
define for the get_base_reg_no macro that returns some valid register
number.
I'll try something, but it'll
On Dec 5, 2005, at 18:11, Roger Browne wrote:
Maybe multidimensional array access using PMC indexes isn't supposed to
be working yet.
I see. Yes you are right. You really can rigth now do the 'easy' cases,
where a compiler knows or infers the involved types, but a general
multi-dim array ac
On Dec 5, 2005, at 21:58, Klaas-Jan Stol wrote:
hi,
if I understood correctly, the global storage is implemented as a hash
table.
If so, will it be possible to load this global hash table in a P
register?
It is possible right now. See the introspection interface of the
interpreter:
perl
On Dec 6, 2005, at 3:43, Stevan Little wrote:
Sorry, I tried to follow docs/submissions.pod, but my patch-fu is very
weak. Please forgive me.
This is a test for C3 MROs, it includes most of the tests from
Perl6::MetaModel prototype in Pugs (which themselves were stolen from
examples in Pyth
tcl and possibly other users of Parrot are currently suffering from
some obscure uninitialized memory bugs, somewhere hidden inside library
loading (see also #37814 and the attached valgrind log).
I've been looking up and down through the code, but there is no obvious
problem. E.g. the invalid
On Dec 6, 2005, at 16:40, Andy Dougherty wrote:
... The structure of the jit_emit.h file is hard to fathom -- it gets
included multiple times by multiple files, and different
implementations
in the jit/*/ directories handle those multiple includes differently.
Yep. Therefore jit/skeleton/ji
On Dec 7, 2005, at 0:29, Michael Cummings wrote:
Problem is the diag message warning users that it will take a while
(and
it does - on a p4 with 2 gigs of ram i gave up after a few minutes
On that hardware it certainly shouldn't need minutes to finish. It's
just strange:
$ time perl -Ilib
On Dec 7, 2005, at 5:39, Bob Rogers wrote:
Turns out this is because of "premature optimization"
Argh - sorry. That shouldn't have been on of course. I did some
benchmarking and must have forgotten to disable it. It is ment to
access the signature array faster. The type of the signature arr
On Dec 7, 2005, at 2:26, Michael Cummings wrote:
I realize I'm talking to myself at this point (last post, promise), but
my last message failed to explain the paste at the top. On a box
without
svk, using the 0.4.0 released tarball, all is fine (t/perl/manifest.t
is
skipped/failed quickly).
On Dec 6, 2005, at 16:08, jerry gay wrote:
On 12/6/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
2) I'm very much inclined to remove the Win32 special casing (see also
r8673)
There are already 2 possibilities to specify the runtime prefix (where
libs are searched).
a) per
On Dec 8, 2005, at 3:13, Bob Rogers wrote:
The change below means that the following code no longer works for
loading non-Parrot compiled libraries from the current directory:
load_bytecode "structures.pbc"
Works here w/o problems. The only issue was that it didn't fail for a
mis
On Dec 8, 2005, at 6:57, Brent Fulgham wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In addition to the shootout machine, I have a main development box
that runs Mac OS X (PowerPC). I attempted to build Parrot 0.4.0 on
this machine and encountered errors. The mailing list archive se
On Dec 8, 2005, at 10:40, Roger Browne wrote:
The recursion limit of 1000 is assigned in inter_create.c and seems
somewhat arbitrary. Is it likely to be raised in the future?
No. But you can raise it in the code ;-)
$P0 = getinterp
$P0."recursion_limit"(1)
Regards,
Roger Browne
On Dec 8, 2005, at 18:54, jerry gay wrote:
chip proposed changing the src/ dir to vm/. nobody complained,
I have said several times that I don't see any reasons to rename src.
There is no benefit at all. And src/ is quite common in distributions
for holding, well, the src.
leo
On Dec 8, 2005, at 3:13, Bob Rogers wrote:
The change below means that the following code no longer works for
loading non-Parrot compiled libraries from the current directory:
load_bytecode "structures.pbc"
I've tested above-like file loading and it worked. OTOH bernhard today
me
On Dec 9, 2005, at 8:24, Brent Fulgham wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 8, 2005, at 1:27 AM, Leopold Toetsch wrote:
Well, having the includes -I./include at the end could be dangerous I
presume.
You are right -- I still had parrot-0.3.1 installed when I
1 - 100 of 5280 matches
Mail list logo
