On Sun, Feb 10, 2013 at 3:03 PM, Gerhard R. wrote:
> On Sun, Feb 10, 2013 at 12:13 AM, Allison Randal wrote:
>>
>> [...] But, it has all the baggage of project legacy, reputation, and
>> relations
>>
>> with other projects, without the advantages of existing code.
>
>
> Publicity wise, it's all i
Perhaps of interest to those working on M0:
http://nominolo.blogspot.ie/2012/07/implementing-fast-interpreters.html
kjs
___
http://lists.parrot.org/mailman/listinfo/parrot-dev
hi there,
The code that M1 spits out for function calls is not correct; it works
only for a single call, but any subsequent calls to either the same or
another function fails. If you put in a print() statement in between,
it usually /does/ work. The generated instructions are based on the
poke_cal
hi there,
M1 is progressing very well. An example of code that runs properly is:
https://github.com/parrot/m1/blob/3db3ee05c6ad056db1c8d1466b86e0cddd261dcb/t/array_and_structs.m1
it's in the M1 repo, t/array_and_structs.m1.
It seems that structs and arrays now work properly, including
combinatio
hi,
There is a symposium on dynamic languages;
http://www.dynamic-languages-symposium.org/
The website is quite well organized with links to the proceedings of
all editions of the symposium so far; proceedings are stored in the
ACM digital library. If you don't have access to the PDFs, let me kno
ah it's always like that. 10 minutes after sending the email, I got it
working. Still buggy I think, but basic value returning works now in
M1!
Explanations are still welcome though :-)
kjs
On Wed, Jun 13, 2012 at 5:35 PM, kjstol wrote:
> hi there,
>
> I'm trying to return v
hi there,
I'm trying to return values from a called subroutine to the caller.
Effectively:
int main() {
int i = foo();
print(i); // should print 42
}
int foo() {
return 42;
}
I'm trying to set the value 42 in a register in the parent call frame
(PCF). However, not much luck.
The more I'm tryin
Greetings,
M1's function calls are now properly working, with many thanks to
Nate++ who explained to me what the code should look like.
I'm eagerly working towards getting the Game of Life running. For that
to run, I need parameters.
Parameter and argument handling however has not been specced. I
glad it works but I'd love it if you continue to target c-m0
> as well. So far you're the first real user of m0 and you're helping to catch
> where the implementation and test suite are incomplete which is a huge help
> to those working on m0.
>
> Nate
>
> On Jun
hi Nate,
just to confirm, I think you're right as for the code that should be
generated. I tried it out with the perl implementation of the M0
interp. It works! I'll keep using the perl interp for now.
cheers
kjs
On Wed, Jun 6, 2012 at 5:58 PM, kjstol wrote:
> hi Nate,
>
>
hi Nate,
On Wed, Jun 6, 2012 at 5:51 PM, Nathan Brown wrote:
> Hey kjs,
>
> No problem, since I helped to get the poke_caller test to pass I figured I
> could help out.
>
> On Jun 6, 2012, at 12:35 PM, kjstol wrote:
>
>> hi Nate,
>>
>> thanks very m
;
> -Nate
>
> On Jun 5, 2012, at 8:12 PM, Nathan Brown wrote:
>
>> Hi kjs,
>>
>> Nothing stands out to me immediately, but I'll try to get m1 working
>> and look at it. From the code excerpts, it looks like it works, but
>> I'd like to see all the
t; that the poke_caller test in the m0 test suite does it.
>
> Hope that helps,
> Nate
>
> On Jun 5, 2012, at 8:35 AM, kjstol wrote:
>
>> hi there,
>>
>> M1's getting more complete by the day. Function invocations and
>> returns are working, _almost_
nd perhaps namespaces are next. Suggestions and feedback and
requests for features are welcome.
Comments welcome,
kjs
On Sun, May 20, 2012 at 2:59 PM, kjstol wrote:
> hi there,
>
> Attached a new version; this does some basic code generation. I'm not
> really familiar with M0 instruc
hi,
M1 is coming along very nicely, it has various features that allows
one to write functional programs.
Missing however is a way to get user input. the print_* instructions
allow to write output; i suspect these ops can go at some point and be
replaced by library functions. Once we get function
esponding label.
>>
>> So, example usage will be
>>
>> $I99 = $I1 - $I0
>> jmpif $I99 le_zero, eq_zero, gt_zero
>>
>> le_zero:
>> ...
>>
>> eq_zero:
>> ...
>>
>> gt_zero:
>> ...
>>
>>
>> --
king there)
>
> Bacek
>
> On May 25, 2012 8:55 PM, "kjstol" wrote:
>>
>> hi there,
>>
>> I'm making nice progress on M1, the C-like language that compiles to M0.
>> However, I'm missing an essential op in M0, which is a comparison op
>>
hi there,
I'm making nice progress on M1, the C-like language that compiles to M0.
However, I'm missing an essential op in M0, which is a comparison op
like < or >. At least one of them is necessary in order to implement
the <, >, <=, >= operators. the unary minus (-x) also could use it,
but addin
hi there,
I've already mentioned this a few times, and also discussed this on
parrotsketch on May 22nd, I've started a little pet project to
implement M1, a simple C-based language to emit M0. You can find it
here:
https://github.com/parrot/m1
Contributions are welcome. I've sprinkled the parser
and simple language implementation
that targets M0. Consider it a prototyping effort to identify gaps in
M0 and see how far we can get with little effort.
cheers
kjs
>
> --
> Bacek
>
>
> --
> Vasily
>
> On Sat, May 19, 2012 at 6:15 AM, kjstol wrote:
>> hi there,
&
hi there,
Was just lurking and thought to chip in here. I seem to remember that
the decision to keep PASM was grounded in the need or desire to have a
"pure" textual representation of the byte code. PASM is much closer
to the byte code than PIR, though not 100% equal.
Having said that, it's prob
Perhaphs have a look at quite a successful other language/interpreter: Lua.
I dont' know details, but Lua is quite successful as a tiny language
that can be embedded.
hth,
kjs
On Mon, Oct 25, 2010 at 2:25 AM, Andrew Whitworth wrote:
> Some people may have seen some recent traffic on my blog [1]
On Fri, Sep 17, 2010 at 6:54 AM, Peter Lobsinger wrote:
> Hi,
>
> As noted this week on #ps, some of the goals we have for 3.0 require
> that some existing functionality be deprecated before they can be
> complete. The 2.9 supported release next month is the last chance to
> get these deprecations
hi there,
In a lost moment, I came across a parrotsketch log where people
wondered what's the deal with PIRC, and that it needs a champion. (for
the new people: I started PIRC) I'm happy to help people by answering
questions or guiding people through the code. However, I have too
little time to do
On Mon, Jun 28, 2010 at 8:40 AM, Peter Lobsinger wrote:
> On Sun, Jun 27, 2010 at 11:50 PM, chromatic wrote:
>> On Sunday 27 June 2010 at 23:05, Peter Lobsinger wrote:
>>
>>> The problem with doing register allocation before IMCC is that IMCC
>>> creates temporary registers and does so in a very
hi,
I agree with Pm. Although I haven't been very active in following
Parrot development in recent times, ideas like these neglect the
rationale of the initial architectural design decisions (see for many
such ideas the blog of Dan Sugalski, still online at
www.sidhe.org/~dan/blog). That is not to
chromatic,
just for my understanding (and other lurkers perhaps), you mean that a
Sub is now stored in the constant table as a Sub PMC, and each of its
attributes is stored as other constants (mostly STRINGs), and you
would prefer to make that one blob? Basically, rather than a "graph"
of constant
On Wed, Dec 2, 2009 at 1:54 PM, jerry gay wrote:
> On Wed, Dec 2, 2009 at 05:03, Andrew Whitworth wrote:
>> I'm inclined to say "yes", but really it's part of a larger set of PIR
>> language features we might want to look into:
>>
>> 1) The ability to say where the PIR code starts, so we can prov
I just have one issue with using flags like :self and :current_sub to
indicate what a particular .param would be, and that's the order.
Using :flags like these implies that you could write:
.sub foo :method
.param pmc x
.param pmc y
.param pmc a :self
.param int b
.param string c :optional
.
hi,
PIRC (like IMCC) generates signatures of ops based on the arguments.
Arguments can be among others keyed thingies, such as:
$P0 = new ["Packfile"]
PIRC currently generates new_p_ksc for the above, which is incorrect.
It should be new_p_pc.
My question (and I'm asking this here on the list ju
Hi all,
A few months ago I started adding bits of documentation on PIRC on the wiki:
https://trac.parrot.org/parrot/wiki/PIRCDevelopment
With the recent mentioning of an increased interest in PIRC by
Whiteknight, I felt I should provide some support.
However, most C functions in PIRC have some d
Hi all,
Just a note on this name "aviary"... (I'm not really following this
thread in detail, just browsing).
The name "aviary" is also the name of a Firefox plugin (capturing
screenshots etc). So, I'm not sure what the idea was with using this
name, but it introduces name conflicts/ambiguity, and
On Sun, Aug 9, 2009 at 10:49 AM, Moritz Lenz wrote:
> Hi,
>
> Igor V. Burago wrote:
>> Dear members of the list,
>>
>> I'm implementing language for science computations similar to Matlab. I
>> found Parrot to be the best
>> solution for that. Syntax of Matlab (which I'm trying to be compatible
On Wed, Jul 29, 2009 at 6:14 PM, Andrew Dougherty wrote:
> On Wed, 29 Jul 2009, Parrot wrote:
>
>> #549: Kill UnionVal
>
>> Comment(by jessevdam):
>>
>> I managed to kill the Unionval form the pobj.h.
>>
>> I replaced the union with the _bufstart and _buflen because there are used
>> by the gc s
On Wed, May 6, 2009 at 3:23 PM, Mark Glines wrote:
> Nick Kostirya wrote:
>> Hello.
>>
>> I have an inherited PASM code from 2004, but modern PASM doesn't have some
>> operations.
>
> And you might want to consider converting to PIR in any case.
>
>
>> Will you please tell me what can be used ins
On Wed, Apr 22, 2009 at 7:41 AM, Stephen Weeks wrote:
> Right now, several HLLs are registering their name (with compreg
> and .HLL) as uppercase, but generating pbcs with lowercase names. For
> example, compreg Perl6 vs. perl6.pbc.
>
> This causes problems with the load_language opcode, possibly
Hi,
it is the plan for PIRC, anyway (and it's not too difficult to finish
that part). However, not high on my priority list. (as in; "anybody
want to help out?" :-)
cheers,
kjs
On Fri, Mar 20, 2009 at 12:40 AM, Will Coleda wrote:
> Do we still expect to be able to generate PASM from PIR? There'
o/~ We're leaving together,
but still its farewell o/~
o/~ And maybe we'll come back,
To earth, who can tell? o/~
o/~ I guess there is no one to blame
We're leaving ground
Will things ever be the same again? o/~
o/~ It's the Final Countdown...
The Final Cou
Tomorrow Parrot 0.9.1 will be released.
If you have any:
* critical bug fixes
* updates
* stuff to be deprecated and removed before 1.0
* anything else you'd like to get in 0.9.1
please commit/add this before tomorrow.
Given the time zone I'm in (GMT), I'm likely to release earlier on the day
than
hi,currently I do not have access to create a new story on parrot.org
Could (Allison, Jerry, Jeff, Will, chromatic).pick help me with that?
thanks!
kjs
___
http://lists.parrot.org/mailman/listinfo/parrot-dev
Do we still need the file LICENSE in the parrot repository, as Parrot
sources are now Copyright Parrot Foundation?
If not, the file can be removed.
cheers,
kjs
___
http://lists.parrot.org/mailman/listinfo/parrot-dev
Dear all,
The 0.9.1 release of Parrot is coming soon, on Tuesday February 17; that's 4
days. If you have anything to add, please consider updating the files
PLATFORMS, CREDITS, RESPONSIBLE_PARTIES and language information at:
https://trac.parrot.org/parrot/wiki/Languages
This release is slightly s
On Fri, Feb 13, 2009 at 12:55 AM, jerry gay wrote:
> On Thu, Feb 12, 2009 at 15:53, Will Coleda wrote:
> > On Thu, Feb 12, 2009 at 6:09 PM, kjstol wrote:
> >> On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT <
> >> parrotbug-follo...@parrotcode.org> wrote:
On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT <
parrotbug-follo...@parrotcode.org> wrote:
> On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote:
> > IMCC currently relies on a lot of static globals to carry state, and
> > cannot reliably restore them when an error occurs. (grep for
> > "st
Hi fellow Parrot hackers,
In less than a week, Parrot 0.9.1 will be released. The last month has been
incredible with respect to fixes, tickets, updates, and whatnot. This is a
Good Thing, obviously. If you have been working on a particular sub-system,
please consider listing the NEWS items. You're
On Fri, Feb 6, 2009 at 1:12 PM, James Keenan via RT <
parrotbug-follo...@parrotcode.org> wrote:
> So here's the current state of what Coke originally posted:
>
> $ cat tclsh.pir
> .HLL 'Tcl'
> .loadlib 'tcl_group'
>
> .sub main :main
> .param pmc argv
> foo(argv)
> .end
>
> .sub foo
> .param pmc a
Hi everyone!
Countdown has started! In T-11 days, the Last Pre-1.0 release of Parrot will
be cut. I would like to check with people that are working on tasks on the
task list on the wiki page https://trac.parrot.org/parrot/wiki/ParrotRoadmap,
to see what the status is. First, though, I would like
.HLL has been changed into a one-operand directive:write .HLL 'Tcl'.
the second operand indicated the (I think) shared lib containing the
language's PMCs, if any. Use '.loadlib' for that. So:
.HLL 'Tcl'
.loadlib 'tcl_group'
is equivalent to the old, deprecated and removed:
.HLL 'Tcl', 'tcl_group'
On Mon, Feb 2, 2009 at 9:16 PM, Andrew Whitworth wrote:
> Current behavior of IMCC is to allow the "self" keyword in ordinary
> subroutines. If "self" is present it's treated like a magical PMC
> variable that is given the value of the first passed parameter. If no
> parameters are passed, you get
I'm working on a little project, using 2 languages in 1 program.The first
parser is needed to parse the 'configuration', which is stored in a file.
The second parser is then needed to parse and handle the command-line input
for user input (it was supposed to be the start of a text adventure engine
On Sun, Feb 1, 2009 at 11:21 AM, François Perrad
wrote:
> 2009/2/1 kjstol :
> >
> > I was doing a first read of the release managers' guide as preparation of
> my
> > first release (eek!), and at the end I noticed the following:
> > [..]
> > - June 16, 2
I was doing a first read of the release managers' guide as preparation of my
first release (eek!), and at the end I noticed the following:
[..]
- June 16, 2009 - 1.3 - whiteknight
- July 21, 2009 - 1.5 - cotto
[...]
Now, I know that there's been discussion about releases and their v
it's been failing for a while (until quite recently, iirc), but now it seems
ok.Just svn up'ed, and nmake'd test; no failures. I'll report any new
failures to trac, if necessary.
thanks for coming back to me.
Ticket can be closed.
kjs
On Sun, Feb 1, 2009 at 12:11 AM, James Keenan via RT <
parrot
On Sat, Jan 24, 2009 at 8:10 PM, Andrew Whitworth wrote:
> Following my investigations into TT#216, and some discussions I've had
> with NotFound, I suggest we deprecate the .HLL_map directive. Some
> points:
>
> 1) .HLL_map fails for classes generated at runtime. See
> compilers/imcc/imcc.y:953 f
On Fri, Jan 16, 2009 at 3:29 PM, Andrew Whitworth wrote:
> I thought I had sent out a reply to this post a little while back, but
> looking through the archives it doesn't look like I actually did
> (which would explain the complete lack of responses!)
>
> On Tue, Jan 6, 2009 at 11:44 PM, Allison
hi,
I'm looking into code I can steal from IMCC for use in PIRC.
I found that I missed creation of a JIT segment (whatever that should do...)
However, I found that parrot builds fine if I remove that function
This is on windows, 32bit (I thought that parrot had a jit for that?)
Anyway, I'd like t
On Thu, Jan 15, 2009 at 6:32 PM, Andrew Whitworth via RT <
parrotbug-follo...@parrotcode.org> wrote:
> Okay, I've committed a variant of my patch in r35599, but I've run into
> some issues while trying to test this. The morph VTABLE interface takes
> an INTVAL which represents the PMC type to morp
On Wed, Jan 14, 2009 at 9:52 AM, kjstol wrote:
>
>
> On Wed, Jan 14, 2009 at 12:54 AM, chromatic wrote:
>
>> On Tuesday 13 January 2009 15:09:24 kjstol wrote:
>>
>> > PIRC absolutely needs this, and in that case it's absolutely safe to
>> us
On Wed, Jan 14, 2009 at 12:54 AM, chromatic wrote:
> On Tuesday 13 January 2009 15:09:24 kjstol wrote:
>
> > PIRC absolutely needs this, and in that case it's absolutely safe to use,
> > as there is no encoding yet: I'm now converting the c-string into a
> STRI
On Tue, Jan 13, 2009 at 11:03 PM, Simon Cozens wrote:
> kjstol wrote:
> > However, I (well, PIRC does) need a string unescape function (taking a
> > c-string) that returns a c-string.
> >
> > Can we add a function to string.c that does in fact just that
>
> &q
hi,
Parrot has a string_unescape_cstring function, which is fine, but returns a
STRING * object.
However, I (well, PIRC does) need a string unescape function (taking a
c-string) that returns a c-string.
Can we add a function to string.c that does in fact just that, and let
string_unescape_cstring
On Tue, Jan 13, 2009 at 10:14 PM, Allison Randal wrote:
> Klaas-Jan Stol wrote:
>
>> hi,
>>
>> There is one minor detail on register allocation unclear to me, regarding
>> PASM registers (in PASM files).
>> When using/specifying PASM registers in PASM code, must these exact
>> registers be used,
On Tue, Jan 13, 2009 at 10:10 PM, Will Coleda wrote:
> Leo!
>
> On Tue, Jan 13, 2009 at 4:45 PM, Leopold Toetsch wrote:
> > Am Sonntag, 11. Januar 2009 18:13 schrieb Geoffrey Broadwell:
> >
> > First, I'm reciting Coke's argument here:
> >
> > "If P42 in PASM acts the same way as $P42 in PIR, wh
On Sun, Jan 11, 2009 at 4:36 AM, Will Coleda wrote:
> On Sat, Jan 10, 2009 at 11:28 PM, Allison Randal
> wrote:
> > Klaas-Jan Stol wrote:
> >> hi,
> >>
> >> There is one minor detail on register allocation unclear to me,
> >> regarding PASM registers (in PASM files).
> >> When using/specifying P
On Wed, Jan 7, 2009 at 5:44 AM, Allison Randal wrote:
> I'm going to start out by taking a step back. First off, define the
> fundamental problem we're trying to solve: accessing classes from
> foreign HLLs. If I've understood Patrick/chromatic, then they agree with
> that.
>
> We're specifically
On Wed, Jan 7, 2009 at 7:57 AM, Allison Randal wrote:
> The fundamental problem in this message is better HLL handling in the
> :multi modifier.
>
> >> .sub 'xyz' :multi(['MyHash'])
>
> The solution for :multi may be quite different than the solution for the
> opcodes: it's a completely diff
examples/library/ncurses_life has some bitrot.
attached a patch that fixes it. I can't test it, but it compiles on my box
(windows).
cheers,
kjs
ncursus_syntax_update.patch
Description: Binary data
___
http://lists.parrot.org/mailman/listinfo/parrot-de
PIRC bytecode generation is coming along nicely lately. I've got most of it
working.Things that need work are generation of bytecode for keys, handling
:outer(), handling :multi().
In order to fully test PIRC I need some extra infrastructure.
Currently, when a load_bytecode instruction is executed
On Wed, Dec 31, 2008 at 5:03 PM, Mark Glines wrote:
> Andy Dougherty wrote:
> > One trap: If the gcc attribute_nonnull is still used for these same
> > functions, gcc can optimize away the NULL checks, rendering them useless.
> > I'd recommend also getting rid of the attribute_nonnull gcc checki
On Mon, Dec 29, 2008 at 11:35 PM, Will Coleda wrote:
> On Mon, Dec 29, 2008 at 5:30 PM, Andrew Whitworth
> wrote:
> > The attached code works and does what you would think it should.
> > However, there is one snag:
> >
> > $P0($P0)
> >
> > This is because when you override the invoke vtable meth
I'm currently implementing/emitting PIR constants (.const) in PBC in PIRC.
Again, I'm running into namespace-like (that is, not .namespace, but
object-type, symbol-like namespaces) issues. What's the desired behavior of:
.const int x = 1
.sub main
.local int x = 2
print x # what should this prin
Coke++
I saw that there's some ticket (I saw 1 anyway) related to JIT. Should we
add that as well?
cheers,
kjs
On Mon, Dec 15, 2008 at 2:14 PM, Will Coleda wrote:
> Added 'pirc', 'imcc', and 'nqp' as components.
>
> On Mon, Dec 15, 2008 at 5:00 AM
hi,
I've started to open tickets for tasks to be done in PIRC in Trac. Could
'pirc' be added as a component in Trac, so that I won't have to use 'None'
(or possibly 'core')?
thanks,
kjs
___
http://lists.parrot.org/mailman/listinfo/parrot-dev
Hi,
If I have read IMCCs source correctly, :immediate subs are executed
immediately after parsing.
So, not after all PIR source has been compiled into bytecode, but as soon as
a particular .sub is compiled, it's run immediately.
This is slightly different from compiling all PIR source into bytec
On Wed, Dec 3, 2008 at 7:25 PM, Will Coleda via RT <
[EMAIL PROTECTED]> wrote:
> On Tue Jan 09 06:43:10 2007, particle wrote:
> > compilers\imcc\imclexer.c(4310) : warning C4018: '<' : signed/unsigned
> > mismatch
> > compilers\imcc\imcc.l(662) : warning C4090: 'function' : different
> > 'const' q
75 matches
Mail list logo
