On Apr 10, 2004, at 12:33 PM, Alberto Manuel Brandao Simoes wrote:
I am not needing parrot (just checking its state) but compilation
failed. Don't know if it is expected or not. In any case, this might
be useful:
../data/locales/ja.txt:15: parse error. Stopped parsing with
On Apr 10, 2004, at 5:43 PM, chromatic wrote:
I'm unable to build Parrot with the new ICU changes. It appears to
fail
in the linking step. I've attached the error output as well as
myconfig
and my Perl 5 config.
This is GCC on Gentoo: gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4
3.2.3-r4,
On Apr 10, 2004, at 1:12 PM, Jeff Clites wrote:
On Apr 10, 2004, at 6:13 AM, Leopold Toetsch wrote:
2) String PBC layout. The internal string type has changed. This
currently breaks native_pbc tests (that have strings) as well as some
parrot xx.pbc tests related to strings.
These are working
I've sent my patch in through RT--it's [perl #28405]!
JEff
On Apr 9, 2004, at 8:07 AM, Dan Sugalski wrote:
At 4:19 PM +0200 4/9/04, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I've sent my patch in through RT--it's [perl #28405]!
Phew, that's huge. I'd really like to have smaller patches that do it
step by step. But anyway, the patch
On Apr 9, 2004, at 7:19 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I've sent my patch in through RT--it's [perl #28405]!
Phew, that's huge. I'd really like to have smaller patches that do it
step by step.
Yes, I know it got quite large--sorry about that, I know it makes
On Apr 7, 2004, at 10:45 AM, Dan Sugalski wrote:
At 10:27 AM -0700 4/7/04, Jeff Clites wrote:
It has taken me longer than I expected to carve out some time to work
on finishing my ICU/string patch, but it's progressing now, and I
just finished tracking down some bugs of mine
It has taken me longer than I expected to carve out some time to work
on finishing my ICU/string patch, but it's progressing now, and I just
finished tracking down some bugs of mine that the config_lib.pasm stuff
was exercising. So I'm currently back to the state of passing all
expected tests
I'm almost finished preparing a patch which incorporates the usage of
ICU, and makes some additional changes to the internal representation
of strings. These changes give us an internal representation model
which is a bit simpler, and is measurably faster. (More details to
follow with the
On Mar 15, 2004, at 7:36 AM, Leopold Toetsch wrote:
Arthur Bergman [EMAIL PROTECTED] wrote:
PDB is too generic ParrotDB_
Of course, ParrotDB sounds like Parrot database
May be its best if someone who has commit privs just changes the
globals
and puts it in - its of not much help to send
On Mar 12, 2004, at 7:14 AM, Dan Sugalski wrote:
At 12:25 PM + 3/12/04, Arthur Bergman wrote:
Hi,
Tracking down test failures in ponie I noticed some tests using
SIGINT failing, they don't fail when I change the tests using
SIGUSR1, making me think that parrot somehow hijacks SIGINT but
On Mar 15, 2004, at 9:30 AM, Dan Sugalski wrote:
At 5:27 PM + 3/15/04, Arthur Bergman wrote:
On 15 Mar 2004, at 17:25, Jeff Clites wrote:
We shouldn't, I would think, be snagging any signals unless user
code expresses an interest in the signal. The default disposition of
every signal
On Mar 15, 2004, at 9:22 AM, Arthur Bergman wrote:
On 15 Mar 2004, at 17:20, Jeff Clites wrote:
We should be able to get the linker to only expose our external entry
points from libparrot. That way, we don't have to worry about the
naming of API which isn't supposed to be called from outside
On Mar 4, 2004, at 7:50 PM, Robert Spier wrote:
IMHO, the releases better include everything necessary to build the
application, within reason. Consistency and simplicity counts for a
lot.
Why create headaches we don't need?
within reason. Thats where we're way off right now.
Let's keep a bit
On Mar 4, 2004, at 2:48 PM, Arcady Goldmints (via RT) wrote:
A few tests are failing with JIT on powerpc linux, even though
everything
works perfectly fine without JIT. The tests in question are
t/op/integer.t 1 and 33, and t/op/stacks.t 1-5. These seem to have in
common the fact that they use
On Mar 4, 2004, at 7:45 AM, Michael Scott wrote:
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib and
install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any
On Jan 26, 2004, at 2:00 AM, Leopold Toetsch wrote:
Michael Scott [EMAIL PROTECTED] wrote:
I see that t/src/io is now failing on OS X 10.3.2. Is anyone else
seeing this on another system?
t/src/iook 12/19# Failed test (t/src/io.t at line
395)
# got: '0
# 0
# 0
# '
#
On Jan 28, 2004, at 6:42 AM, Peter Haworth wrote:
On Thu, 15 Jan 2004 23:00:53 -0800, Jeff Clites wrote:
I think we shouldn't try to do any sort of cross-language unification.
That is, if we some day have a Parrot version of Java, and in Perl6
code I
want to reference a global created inside
On Jan 27, 2004, at 3:47 PM, Cory Spencer wrote:
Perhaps someone with a bit more familiarity with the Parrot IO
subsystem
could give me some guidance here. I'm currently trying to get a new
'peek' opcode working, and I'm having difficulties getting the io_unix
layer implemented correctly.
As
On Jan 27, 2004, at 7:29 AM, Leopold Toetsch wrote:
getinterp P5
dlfunc P0, Nul, Parrot_UnManagedStruct_get_pointer, pIP
...
This is unlimited self-inspection and self-modification :) With little
additions (nested structs) one could read/write all Parrot_Interp
internals
On Jan 17, 2004, at 12:33 PM, Leopold Toetsch wrote:
Gordon Henriksen [EMAIL PROTECTED] wrote:
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Ops that can leave the code segment have to explicitely check for
events.
But if the event dispatch thread is setting some flag for the
On Jan 17, 2004, at 2:58 AM, Leopold Toetsch wrote:
Damien Neil [EMAIL PROTECTED] wrote:
The JVM is a stack machine. JVM opcodes operate on the stack, not on
main memory. The stack is thread-local. In order for a thread to
operate
on a variable, therefore, it must first copy it from main
On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Where in the stream would we patch? If not in a loop, you may never
hit
the single patched location again, but still might not end for a very
long time
Same as with prederefed run cores: backward
On Jan 15, 2004, at 9:52 AM, Dan Sugalski wrote:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Here are some notes on namespaces, picking up a thread from about a
month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
On Jan 15, 2004, at 8:26 PM, Benjamin K. Stuhl wrote:
Thus wrate Dan Sugalski:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Short version: I was originally going to argue for fully
hierarchical namespaces, identified as above, but after turning this
over in my head for a while, I came
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Damien Neil [EMAIL PROTECTED] wrote:
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic
access to
On Jan 15, 2004, at 10:42 PM, chromatic wrote:
On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
I tried that as well, it spits out identical PASM each time but on the
odd occasion I need to use CTRL-C to get back to the shell.
I'm seeing the same thing on Linux PPC -- odd hangs from time to
On Jan 15, 2004, at 3:33 PM, Jonathan Worthington wrote:
- Original Message -
From: Dan Sugalski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 15, 2004 8:09 PM
Subject: Unicode, internationalization, C++, and ICU
Now, assuming there's still anyone left reading this
On Jan 16, 2004, at 1:01 PM, Damien Neil wrote:
On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Yes, that's what I'm saying. I don't see an advantage of JVMs
multi-step
variable access, because it even doesn't provide such atomic
On Jan 16, 2004, at 1:20 PM, Leopold Toetsch wrote:
Gordon Henriksen [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
2) Patch the native opcodes at these places with e.g. int3
I don't think that bytecode-modifying versions should fly; they're not
threadsafe,
Why? The bytecode is patched by a
On Jan 12, 2004, at 10:03 AM, Gordon Henriksen wrote:
On Monday, January 12, 2004, at 04:29 , Jeff Clites wrote:
5) Java seems to use a check-in/check-out model for access to global
data, in which global data lives in a central store, but is copied
back-and-forth to thread-local storage
Here are some notes on namespaces, picking up a thread from about a
month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
opcodes. If we're going hierarchic, and we want to separate out the
name from the namespace, that
This is a threading proposal, in the form of a collection of notes.
Rationale:
We need to constantly compare parrot to the JVM, and in particular have
a deep understanding of cases where the JVM performs well (or better
than parrot). The reason for this is obvious: the JVM is the product of
On Jan 12, 2004, at 8:07 AM, Harry Jackson wrote:
Dan Sugalski wrote:
Having a fetchrow_hash that returned a Hash where the keys are the
column names and the values are the column values would be most of
the rest.
I read somewhere that accessing a hash was slightly slower than
accessing and
On Jan 11, 2004, at 3:10 AM, Leopold Toetsch wrote:
Bernhard Schmalhofer [EMAIL PROTECTED] wrote:
'make fulltest' gives 6 reports. 5 reports for different parrot
options plus
1 report for t/src/*.t.
Dou you see a simple way, to run all tests in one harness for
fulltest. That would need some
On Jan 10, 2004, at 6:50 AM, Harry Jackson wrote:
# New in libpq.so.3.1
t pt
p ptit33i
i ptit33i
i ptiit33i
c pi
I have jsut added the above signatures to my call_list due to an
upgrade to postgres and was wondering what plans are there for
managing the
On Jan 10, 2004, at 11:54 AM, Nicholas Clark wrote:
On Sat, Jan 10, 2004 at 08:39:51PM +0100, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
src/dod.c: In function `clear_live_bits':
src/dod.c:755: `cur_arena' undeclared (first use in this function)
The appended patch cures it
On Jan 9, 2004, at 12:24 AM, Leopold Toetsch wrote:
Michal Wallace [EMAIL PROTECTED] wrote:
#!/bin/env parrot
#
# yieldbug.imc
#
# This program should print dots forever.
# Instead it prints a few dots and then segfaults.
It does print dots forever here.
It does for me too. But based on a
What does restart mean in op files, as in restart ADDRESS(resume);?
Also, why does the find_global op use it? I couldn't find it explained
anywhere.
Also, on a vaguely related topic, in Parrot_jit_cpcf_op, what does
cpcf stand for?
JEff
On Jan 7, 2004, at 8:15 PM, Melvin Smith wrote:
Leopold Toetsch writes:
Jeff Clites [EMAIL PROTECTED] wrote:
On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
Exactly the latter:
That was AFAIK a design decision, when Dan did introduce CPS. At
this
time register backing stacks went out
On Jan 7, 2004, at 10:39 AM, Adam Thomason wrote:
The 40 ops range from 0x200fca28 to 0x200fca90, with 0x200fca94 onward
being
.long 0x0. The pc at failure is 0x7c0802a4. So it's probably safe
to
assume the trouble is pre-pasm.
Yep, you're right. Thanks for all of the great information--I'm
On Jan 8, 2004, at 4:24 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I think I'm just being dense, but looking at
include/parrot/interpreter.h it appears that they are in the context:
Sorry, yes. They are in the context but not saved. I mixed that up with
the registers
On Jan 6, 2004, at 3:28 PM, Adam Thomason (via RT) wrote:
-Original Message-
From: Jeff Clites [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 31, 2003 4:30 PM
To: [EMAIL PROTECTED]
Subject: [PATCH] PPC JIT fixes [re-send] (Modified by Jeff Clites)
7) I don't expect anything here
On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
That part is already answered: create a buffer_like structure.
*But* again
On Jan 5, 2004, at 9:37 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Jan 5, 2004, at 5:32 AM, Leopold Toetsch wrote:
The return value is only returned, when I3 != 0. For your example
that
shouldn't be the case (I3 is unused aka zero). So there isn't any
return
value
{This is a re-send of my submission [perl #24789] from 12/31, which has
not been forwarded from RT. I wanted to keep this separate from my
subsequent [perl #24808] in order to preserve the change history.}
Attached is a patch which fixes most of the make testj failures on
Mac OS X (ie, ppc
[ apologies for the duplicate email message from my last post--mail
client problems... ]
On Jan 6, 2004, at 11:50 AM, Simon Cozens wrote:
Jeff Clites:
$a = $hash{bar};
Here you used the copy constructor before taking the reference. It
might look
like an assignment operator, but it isn't
On Jan 6, 2004, at 9:25 AM, Leopold Toetsch wrote:
Arthur Bergman [EMAIL PROTECTED] wrote:
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is
right.
$foo = \$hash{key};
$$foo = bar;
$has{key} is now bar
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
Leopold Toetsch writes:
Good. Pass it over to me :) COW copy of stacks and of other
buffer-based
items is still broken. These need distinct headers so that they work
like COWed strings.
Alright, I've got a pretty big incomplete patch here (see, when
On Jan 6, 2004, at 6:42 PM, Luke Palmer wrote:
Jeff Clites writes:
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
To do that properly, I think you need a pobj_t
If I run this code, which should just be a loop which
creates-then-joins a thread (looping twice), I get a crash at the end:
set I16, 0
again:
inc I16
new P5, .ParrotThread
find_global P6, _foo
find_method P0, P5, thread3
invoke
set I5, P5
getinterp P2
On Jan 5, 2004, at 5:47 AM, Luke Palmer wrote:
After many months of lying dormant, I figured I'd get my act together
and adapt this patch to the few recent modifications. And this time,
I'm posting a benchmark!
My results get about 5% slowdown in the eager case, and the usual
10,000% speedup in
On Jan 5, 2004, at 5:32 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
If I run this code, which should just be a loop which
creates-then-joins a thread (looping twice), I get a crash at the end:
The problem is that when joining the _second_ time, in
pt_thread_join()
you get
On Jan 4, 2004, at 5:47 AM, Leopold Toetsch wrote:
Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
When you use an external library in Perl, such as e.g. libxml, you
have Perl data-structures and libxml data-structures. The Perl
data-structures contain pointers to the libxml data-structures.
In
On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock().
Completely specious, and repeatedly proven unwise.
On Jan 4, 2004, at 1:58 PM, Matt Fowles wrote:
Dave Mitchell wrote:
Why on earth would they be all one kernel-level thread?
Truth to tell I got the idea from Ruby. As I said it make
syncronization easier, because the interpreter can dictate when
threads context switch, allowing them to only
On Jan 3, 2004, at 11:19 AM, Elizabeth Mattijsen wrote:
At 01:48 -0500 1/3/04, Uri Guttman wrote:
NS == Nigel Sandever [EMAIL PROTECTED] writes:
NS All that is required to protect an object from corruption
through
NS concurrent access and state change is to prevent two (or more)
VMs
NS
On Jan 3, 2004, at 10:08 AM, Elizabeth Mattijsen wrote:
At 12:15 -0500 1/3/04, Uri Guttman wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK()
pair.
LT
On Jan 3, 2004, at 12:26 PM, Uri Guttman wrote:
LT These are platform specific details. We will use whatever the
LT platform/OS provides. In the source code its a LOCK() UNLOCK()
pair.
LT The LOCK() can be any atomic operation and doesn't need to call
the
LT kernel, if the lock is
On Jan 3, 2004, at 2:59 PM, Leopold Toetsch wrote:
Nigel Sandever [EMAIL PROTECTED] wrote:
Only duplicating shared data on demand (COW) may work well on systems
that support COW in the kernel.
No, we are dealing with VM objects and structures here - no kernel is
involved for COWed copies of e.g.
On Jan 3, 2004, at 5:24 PM, Matt Fowles wrote:
All~
I have a naive question:
Why must each thread have its own interpreter?
The short answer is that the bulk of the state of the virtual machine
(including, and most importantly, its registers and register stacks)
needs to be per-thread, since
On Jan 1, 2004, at 11:31 PM, Robert Spier wrote:
I submitted a patch yesterday to [EMAIL PROTECTED],
and received the automated response (the ID is [perl #24789]), but it
doesn't seem to have been forwarded to the mailing list. Is something
up with the tracking system?
Nothing is up. It's in the
I submitted a patch yesterday to [EMAIL PROTECTED],
and received the automated response (the ID is [perl #24789]), but it
doesn't seem to have been forwarded to the mailing list. Is something
up with the tracking system?
JEff
On Jan 1, 2004, at 9:43 AM, Josh Wilmes wrote:
At 16:15 on 12/30/2003 EST, Dan Sugalski [EMAIL PROTECTED] wrote:
Your constraints:
2) A perl 5 iThreads it's not a thread, it's a fork. Well, sorta...
mode must be available
For those of us who aren't particularly familiar with ithreads, what
On Dec 30, 2003, at 5:19 PM, Harry Jackson wrote:
I have also tried strace and got the following.
Try this on parrot rather than Perl.
strace on parrot gets to
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
wait4(-1, [WIFEXITED(s) WEXITSTATUS(s) == 0], 0, NULL) = 8423
--- SIGCHLD (Child exited)
On Dec 29, 2003, at 11:48 AM, Dan Sugalski wrote:
As I see it, it's really the allocation that is more complicated with
a mark-and-sweep collector (since you have to search for a
correct-sized free chunk, efficiently)--the collection itself is the
easy part. Actually, it seems like this is
On Dec 30, 2003, at 11:18 AM, Dan Sugalski wrote:
At 11:27 AM -0500 12/30/03, Gordon Henriksen wrote:
I wish the threading design for parrot would look more toward
successful, performant multithreaded systems,
I'm going to be really grumpy here, though it's not directed at
Gordon. What *I* wish
On Dec 29, 2003, at 2:12 PM, Harry Jackson wrote:
During
[EMAIL PROTECTED] parrot]$ make test
echo imcc/imcc.y -d -o imcc/imcparser.c
imcc/imcc.y -d -o imcc/imcparser.c
perl -e 'open(A,qq{$_}) or die foreach @ARGV' imcc/imcc.y.flag
imcc/imcparser.c imcc/imcparser.h
perl t/harness --gc-debug
On Dec 30, 2003, at 3:11 PM, Harry Jackson wrote:
2) Try running one of the tests which blocks, individually. If you
can get it to happen this way, then run it in gdb and see what it's
doing. (Or, attach to an already blocked one from 'make test'--this
is assuming it's parrot that's actually
On Dec 29, 2003, at 8:13 AM, Dan Sugalski wrote:
2) We need a more traditional, non-moving GC as an alternative to the
copying collector. A modified mark sweep'd be fine, but as it'll be
living behind the API it doesn't much matter.
This is really only for the chunks of memory backing strings
On Dec 28, 2003, at 1:42 AM, Leopold Toetsch wrote:
Joe Wilson [EMAIL PROTECTED] wrote:
Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on
I don't think that Dan meant that Python-on-Parrot would be 20x faster.
He's saying that it's easy to speed up Python if you leave out the slow
parts, and that the Python-on-.NET implementation has left out the slow
parts so far. So when it's complete, Python-on-.NET will end up slower
than
On Dec 23, 2003, at 4:08 PM, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
Speaking personally, being able to automatically convert a Parrot
array
to an array of ints or floats would be very useful, but that's
because I
do fairly hard-core number crunching in my day job. What
On Dec 22, 2003, at 2:48 PM, Melvin Smith wrote:
At 11:02 AM 12/22/2003 -0700, Cory Spencer wrote:
The program I'm writing is passing a ParrotIO object about to various
functions (the ParrotIO object being either stdin or a file handle to
a
regular file). Each function can read as many bytes as
On Dec 22, 2003, at 6:57 AM, Dan Sugalski wrote:
At 11:44 AM -0800 12/20/03, Jeff Clites wrote:
On Dec 20, 2003, at 1:54 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
The issue turns out to be that SIGFPE isn't raised on Mac OS X on
divide by zero. If I hack src/core_ops.c
On Dec 20, 2003, at 1:54 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
The issue turns out to be that SIGFPE isn't raised on Mac OS X on
divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE)
in
the case of zero divisor then the tests pass, so the exception
On Dec 17, 2003, at 11:24 AM, Leopold Toetsch wrote:
Allison Randal [EMAIL PROTECTED] wrote:
$ parrot t/op/hacks_1.pasm
not reached
...
Does Fruntime/parrot/include/signal.pasm have an entry for SIGFPE?
Is PARROT_HAS_HEADER_SIGNAL defined?
Yes to both questions.
The issue turns out to be that
On Dec 10, 2003, at 12:37 AM, Luke Palmer wrote:
Dan Sugalski writes:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1[Foo\x00i] # I1 == I2
gets currently the attribute idx (0) of $Foo::i.
Q: Should the assembler mangle the Foo::i to Foo\0i
I don't like it either, but the
I have some other fixes for this--I'll clean them up and send them in.
I got something working which doesn't crash, and which can find
libraries in standard locations w/o knowing the path. It uses the
native dyld API rather than dlopen--the dlopen which shipped with
Panther is just the
On Dec 9, 2003, at 3:40 PM, Dan Sugalski wrote:
At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote:
Melvin Smith [EMAIL PROTECTED] wrote:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1[Foo\x00i] # I1 == I2
gets currently the attribute idx (0) of $Foo::i.
Q: Should the
On Dec 3, 2003, at 12:03 PM, Dan Sugalski wrote:
At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
*) Exceptions we're happy with
Create an Exception class hierarchy?
I'm not 100% sure I want to go with a real OO style of exceptions, but
that might just
On Dec 2, 2003, at 8:49 PM, Melvin Smith wrote:
At 07:59 PM 12/2/2003 -0800, Steve Fink wrote:
On Dec-02, Melvin Smith wrote:
Do you really want to generate the extra unused code at the end of all
the subroutines? I don't think you want to autodetect whether the code
is guaranteed to return.
On Dec 1, 2003, at 9:01 PM, Melvin Smith wrote:
At 10:40 AM 11/28/2003 +0100, Leopold Toetsch wrote:
As outlined some time ago, when ops.num made it into the core, we
need fix assigned PMC class enums too. (Changed class enums
invalidate existing PBC files).
1) lib/Parrot/PMC.pm is the
On Nov 19, 2003, at 9:04 AM, Dan Sugalski wrote:
Just a quick heads-up--I checked in the preliminary patch for
freeze/thaw
that Leo sent me for review. It'll change internally a fair amount, and
the vtable/low-level API is going to change, but the op-level interface
will be stable. I wanted it
On Nov 19, 2003, at 1:34 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 19, 2003, at 9:04 AM, Dan Sugalski wrote:
Two initial concerns:
1) I have a patch which I've been assembling to do ordered
destruction.
That needs to use the next_for_GC pointer (and I think any
On Nov 17, 2003, at 11:22 AM, Melvin Smith wrote:
In the past couple of years we've seen several sub-projects pop-up
and subsequently fizzle out (maybe due to Parrot slow
progress or maybe due to lack of critical mass).
I propose creating 'parrot-compilers' as a general
purpose list for any and
On Nov 17, 2003, at 11:07 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
My main point is that you can't do conditional library loading. This
code will try to load the doesnt_exist library, and I don't think it
should:
branch HERE
loadlib P1, doesnt_exist
On Nov 18, 2003, at 9:07 AM, Sterling Hughes wrote:
The reason I think parrot-compilers would be useful, is that its
dedicated to helping people (like me) write compilers for parrot,
whereas (in my understanding), perl6-internals@ is really about the
development of the vm itself (I would
On Nov 17, 2003, at 1:59 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I've run into a couple of issue with library loading which have their
origin down inside the IMCC code:
1) External libraries are being loaded at parse time.
Inside of INS() in imcc/parser_util.c
I've run into a couple of issue with library loading which have their
origin down inside the IMCC code:
1) External libraries are being loaded at parse time.
Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is called at
parse-time when loadlib is encountered. This is causing libraries
Hi Chris:
I haven't had any problems such as this on Mac OS X--either 10.2.6 or
10.3. What is the contents of your myconfig file? Here is the
contents of mine, for comparison:
Summary of my parrot 0.0.13 configuration:
configdate='Fri Nov 14 18:23:39 2003'
Platform:
osname=darwin,
On Nov 13, 2003, at 2:21 PM, Nicholas Clark wrote:
On Wed, Nov 12, 2003 at 02:07:52PM -0800, Mark A. Biggar wrote:
And even when the sequence of Unicode code-points is the same, some
encodings have multiple byte sequences for the same code-point. For
example, UTF-8 has two ways to encode a
On Nov 6, 2003, at 11:56 PM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
An alternative (which may or may not a good one) would be to say that
you can never actually store a NULL in a hash
Not good. The Hash (now) may take almost arbitrary key/value pairs.
Value can be plain ints
Pretty much the exact same results on Mac OS X. Here's the contents of
myconfig:
Summary of my parrot 0.0.13 configuration:
configdate='Sat Nov 8 18:40:54 2003'
Platform:
osname=darwin, archname=darwin
jitcapable=1, jitarchname=ppc-darwin,
jitosname=DARWIN, jitcpuarch=ppc
On Nov 6, 2003, at 10:05 AM, Juergen Boemmels wrote:
But I still have one problem: hash_put and hash_get are not
symmetric. hash_put puts a void *value, but hash_get returns a
HASHBUCKET. This looks wrong to me.
When returning the value directly, we couldn't have NULL value's - or
better NULL
On Oct 28, 2003, at 3:56 PM, Luke Palmer wrote:
Object Instantiation
Dan had a moment of clarity and declared that the Parrot Way to
instantiate an object in class Foo will be:
new P5, .Foo
All we need now is a working implementation. And, apparently,
knowing
what class
On Oct 27, 2003, at 6:21 AM, Dan Sugalski wrote:
On Fri, 24 Oct 2003, Gordon Henriksen wrote:
On Monday, October 20, 2003, at 11:40 , Jeff Clites wrote:
My solution was to define a new vtable method--I've called it
visit(),
though the name's not the important part--to which you pass
On Oct 26, 2003, at 10:39 AM, Melvin Smith wrote:
I think a compromise would be to do define a interpreter global PMCNull
and point (or init) all Px registers to it.
...
The downside is fast initialization of register blocks. memsetting
with NULL (0)
will not be possible, but I'd have to
On Oct 21, 2003, at 8:11 AM, Juergen Boemmels wrote:
If you think about it: The call to the destructors is done after
free_unused_pobjects completed. The memory of the objects without
destructors is already freed. If you are still in an out of memory
situation when the destructors are run, then
On Oct 21, 2003, at 7:14 AM, Dan Sugalski wrote:
After thinking about this a bit, it became glaringly obvious that the
right way to instantiate an object for class Foo is to do:
new P5, .Foo
Or whatever the constant value assigned to the Foo class upon its
creation
is. When a class is
201 - 300 of 321 matches
Mail list logo
