Paul C. Anagnostopoulos wrote:
At 9/18/2010 01:22 PM, Jonathan Leto wrote:
Or, as an alternative, has an interactive mode that asks questions.I'd love to get started using Parrot without first having to learn a
bunch of inscrutable arguments and options.
Let me add a note of perspective
Jonathan Leto wrote:
Howdy,
Do we want to port both mk_language_shell.pl and create_language.pl to git,
or only one? Are both considered supported?
I find that having both confuses a lot of people new to Parrot.
Note that these issues are being currently discussed in
http://trac.parrot.or
Hello.
On Sun, Sep 19, 2010 at 7:41 AM, Luben Karavelov wrote:
> On Sat, 18 Sep 2010 19:09:26 +0200, Nick Wellnhofer
> wrote:
>>
>> So you propose to replace every vtable function that does an
>> assignment to a PMC or STRING with a second version?
>>
>
> Yes, that's the idea. For generational G
On Sat, 18 Sep 2010 19:09:26 +0200, Nick Wellnhofer
wrote:
>
> So you propose to replace every vtable function that does an
> assignment to a PMC or STRING with a second version?
>
Yes, that's the idea. For generational GC we replace original
vtable with the modified vtable when we move an ob
Howdy,
It looks like http://trac.parrot.org/parrot/wiki/Languages needs some love.
All the smolder links need to be updated, some spec test links have moved to
git, and some languages should probably be moved to the Inactive table.
If you are an HLL author that hasn't looked there in a while, or
Howdy,
>Or, as an alternative, has an interactive mode that asks questions. I'd
love to get started >using Parrot without first having to learn a bunch of
inscrutable arguments and options.
I think that is a great idea, and need not be "an alternative". Going
interactive if no command line argume
At 9/18/2010 01:22 PM, Jonathan Leto wrote:
>My idea: create one unified tool that accepts command line arguments for
>choosing the kind of build system.
Or, as an alternative, has an interactive mode that asks questions. I'd love to
get started using Parrot without first having to learn a bunc
Howdy,
Do we want to port both mk_language_shell.pl and create_language.pl to git,
or only one? Are both considered supported?
Neither currently have any tests. They are basically the same, except
create_language creates a Perl/make-based build,
vs a distutils-based build in mk_language_shell .
On 18/09/10 17:07, Vasily Chekalkin wrote:
On Sat, Sep 18, 2010 at 11:20 PM, Nick Wellnhofer wrote:
On 18/09/10 06:06, Luben Karavelov wrote:
The idea is that we could dynamically swap vtables of objects that
should be
barriered. The new vtable will contain functions that execute
barrier-ing
At 9/18/2010 11:07 AM, Vasily Chekalkin wrote:
>1. It does. All "assignments" are actually vtable calls. E.g.
>VTABLE_set_integer_native, etc.
Unless some vtable functions have been optimized to set attributes directly. I
would think that many init() functions do this.
~~ Paul
_
On Sat, Sep 18, 2010 at 11:07 AM, Vasily Chekalkin wrote:
> On Sat, Sep 18, 2010 at 11:20 PM, Nick Wellnhofer wrote:
>> On 18/09/10 06:06, Luben Karavelov wrote:
>>>
>>> The idea is that we could dynamically swap vtables of objects that
>>> should be
>>> barriered. The new vtable will contain fun
Howdy,
Thanks Moritz, that really helps! I can think of one other issue though:
back-compat.
Currently, every Parrot-based project that exists asks parrot_config for the
"revision" key, which it expects to be an integer, and compares it to the
integer stored in the PARROT_REVISION file.
This mea
On Sat, Sep 18, 2010 at 11:20 PM, Nick Wellnhofer wrote:
> On 18/09/10 06:06, Luben Karavelov wrote:
>>
>> The idea is that we could dynamically swap vtables of objects that
>> should be
>> barriered. The new vtable will contain functions that execute
>> barrier-ing
>> logic (card marking, scaveng
On 18/09/10 06:06, Luben Karavelov wrote:
The idea is that we could dynamically swap vtables of objects that
should be
barriered. The new vtable will contain functions that execute
barrier-ing
logic (card marking, scavenging etc.) and re-dispatch to the original
vtable
function.
That simply doe
This is the last reminder to Parrot 2.8.0. Parrot 2.8.0 will be released
in three days. I will switch the version at 2010-09-21 08:00 UTC.
To convert UTC to your local time run:
$ date -d '2010-09-21 08:00 UTC'
Let's hold further branch merges, and focus on testing prior to the
release.
The c
This is the last reminder to Parrot 2.8.0. Parrot 2.8.0 will be released
in three days. I will switch the version at 2010-09-21 08:00 UTC.
To convert UTC to your local time run:
$ date -d '2010-09-21 08:00 UTC'
Let's hold further branch merges, and focus on testing prior to the
release.
The c
16 matches
Mail list logo
