In the spectest suite (specifically in: t/spec/S32-array/kv.t), the last
several tests seem to be testing for named arguments to kv:
# check the non-invocant form with named arguments
my @array = a b c d;
my @kv = kv(:array(@array));
#?rakudo skip 'named args'
is(+...@kv,
Subversion's OK, but I would definitely prefer git. I've only used it
for a few small projects, but already it's impressed the heck out of me
for its behavior in both big things (branching) and small things (git
diff automatically pages).
Perhaps a response to this thread is a little late,
I've got a question regarding Ranges and in particular, infinite
Ranges. How should a range such as:
(0..Inf)
or
(-Inf..0)
be represented when it is converted to a string? I believe that Pugs
currently attempts to create a range of infinite length and provides
no stringified value. I'm
I'm closing this bug as 'rejected' because a corrected patch was never
submitted. If you ever get it work, please do resubmit it.
Actually, I believe it was eventually applied, although I'm not sure why
it wasn't updated in the RT. In any event, two peek opcodes currently
exist in the
On Fri, 22 Apr 2005, Matt Diephouse wrote:
- (defun (square x) (* x x))
T
- (square 2)
*** ERROR: SQUARE is not a function name
A quick follow-up - I've just checked in code implementing some primitive
macros, so if you wanted to give (defun ...) a go again, you should find
that it works now.
- (defun (square x) (* x x))
[...]
*** ERROR: SQUARE is not a function name
Is that because (a) that's not implemented yet or (b) I'm doing
something wrong? I haven't found the time to delve into the source
yet.
Oops, that wasn't supposed to have made it in there - I haven't finished
up macros
I've encountered some multimethod dispatch funnyness tonight. The
included code which one would expect to produce a value of 1 ends up
printing a value of 3.
Changing a and b to be regular Integer types seems to work. Can
anybody shed any more light on this?
-c
.sub _main @MAIN
.local pmc
(If anyone is able to track down aforementioned DOD/GC problems,
you'll earn my eternal gratitude.)
Can you please provide a code snippet that exhibits the error.
Just running the program gives me errors on both Linux/x86 and OS X.
Running with GC disabled works fine.
On OS X with GC
I'd like to announce the creation of the Parrot Common Lisp project, which
aims to implement a significant subset of the Common Lisp language. At
present it's nowhere near achieving that goal, but it's progressing slowly
as I figure out the intricacies of writing a Lisp implementation.
A
The latest Parrot CVS checkout segfaults for me on the following code:
.sub _main
.local pmc foo
foo = new Integer
foo = 3
# new_pad 0
store_lex foo, foo
end
.end
It appears that the store_lex opcode is to blame - when no lexical pad
has been created and you
Just a quick question:
Is there currently any method of determining the depth of the lexical
scope pad stack? None of the ops in var.pod seem to be able to provide
that information at the moment...
Cory
Is there currently any method of determining the depth of the lexical scope
pad stack? None of the ops in var.pod seem to be able to provide that
information at the moment...
Actually, I suppose I should clarify what I want to get at here, which is
when lexical pads popped off the stack. Am
I've been writing a Lisp implementation on top of Parrot for the last
several months (and I'm just about at the point where I'm ready to unleash
it upon the world). I seem to have run up against some issues which
*appear* to be related to the garbage collector collecting objects that
aren't
Is is possible to check to see whether an attribute exists on a given
object, or at least catch an exception if it doesn't? I've tried to set
up an exception handler, but Parrot exits without anything being caught.
A code snippet follows:
.sub _main
.local pmc class
.local int type
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 far as I know, I'd get a call down into the io_unix
'peek' implements an opcode which can look ahead at an arbitrary number of
bytes in a IO stream, but does not remove the bytes from the stream in the
process.
[...]
I have some question though:
- what if peek wants to look beyond current buffered limits
Yes - at present it only
for Parrot?
Regards,
Cory Spencer
Is it possible to unread characters from an input stream in Parrot? (ie.
if I do a read char, 1, decide later than I don't want the character so
I push it back on the stream)
Failing that, is it possible to peek ahead at a character without
necessarily taking it off the stream?
Can anyone tell me why the following code:
.sub _main
.local PerlUndef val
val = new PerlUndef
_foo(bar, val)
end
.end
.sub _foo
.param string v1
.param pmc v2
.pcc_begin_return
.return 1
.pcc_end_return
.end
We're already using 'eq' to perform equality testing, and in the interests
of maintaining a consistent design I would choose to stick with something
eq-related as opposed to changing it to 'same'.
eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
So just to follow up on this thread, was
I don't think there was ever a consensus about opcode naming.
It seems that we need this but can you give an example
of where you are using it, just to give me some context to think
with?
I've been implementing a Lisp interpretter (and hopefully at some point,
compiler) and was using the
I've been hard pressed to find any examples of proper exception-raising
with Parrot
t/pmc/exception.t
Excellent, thank you.
I've been hard pressed to find any examples of proper exception-raising
with Parrot - reading back through the list in June/July I see that there
was some starts at implementing various exception related bits - has this
been at least semi-completed?
However, if giving up IMCC's register allocator is worth gaining
the extra control of PASM, by all means do it, however I'm all ears
on suggestions for IMCC for features. *hint*
In that case, I don't suppose it would be possible for IMCC to allow
function calls in an if expr goto LABEL
On Fri, 28 Nov 2003, Leopold Toetsch wrote:
Op vtable Meaning
- is_same PMCs are ident
- is_equal PMCs are equivalent, holding the same value
Y cmp cmp PMCs
- cmp_num cmp PMCs numerically
- cmp_string cmp PMCs as strings
Proposals for opcode names
On Fri, 28 Nov 2003, Leopold Toetsch wrote:
Op vtable Meaning
- is_same PMCs are ident
- is_equal PMCs are equivalent, holding the same value
Y cmp cmp PMCs
- cmp_num cmp PMCs numerically
- cmp_string cmp PMCs as strings
Proposals
I think this is definitely something we should do if we want to confuse
people as much as possible :-)
This is likely true, seeing as I *still* have troubles keeping the various
Lisp eq/eql/equal/equalp's straight. ;)
I would therefore vote that we keep these opcodes as verbose as
possible.
We're already using 'eq' to perform equality testing, and in the interests
of maintaining a consistent design I would choose to stick with something
eq-related as opposed to changing it to 'same'.
eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
Oops, correction there - I'd forgotten an
Is there any way in PASM to determine whether or not two PMC's share the
same memory address?
That is, for example, given the following IMC snippet:
.sub _eq
.param pmc arg1
.param pmc arg2
.local int retv
...
...
.pcc_begin_return
Hey folks -
In my wanders through the parrot/languages subdirectories, it appears that
most example languages implement a complete compiler (ie lexxer - parser
- optimizer - code emitter), which seems to be somewhat of a
duplication of labour. Has or is anyone worked on a framework a la gcc
30 matches
Mail list logo
