On Mon, Oct 24, 2011 at 2:51 PM, Kevin Polulak wrote:
> The problem I'm having is with recursively adding directories to an archive.
> The libzip library provides a function called zip_add_dir() that is supposed
> to do this. Unfortunately, it has no relation to the user's fileystem
> outside the
On Thu, Oct 13, 2011 at 2:35 PM, Will Coleda wrote:
> On Wed, Oct 12, 2011 at 6:28 PM, Jonathan "Duke" Leto
> wrote:
>> Howdy,
>>
>> There is a new dashboard for organizations that shows all of their issues:
>>
>> https://github.com/organizations/parrot/dashboard/issues
>>
>> This is a great vie
On Thu, Sep 22, 2011 at 3:23 PM, Stefan Seifert wrote:
> Hi,
>
> I'm trying to pick up Chandler's threading work in the gsoc_threads branch.
> First step would be to bring it up to date wrt current master (pre
> kill_threads to be precise). I branched green_threads off gsoc_threads and
> merged ma
build fixed in 851a2aaf17c2eb73abb25c8b5b735ab93089e8ad, test fixed in
081805293b792d4664556aeab79e14702505886e
On Wed, Sep 21, 2011 at 10:59 PM, James E Keenan wrote:
> On 9/21/11 10:41 PM, James E Keenan wrote:
>>
>> On 9/21/11 10:27 PM, James E Keenan wrote:
>>>
>>> commit 55a6542
>>> branch:
About a week ago, I sent out an RFC about getting rid of some of the
vtables on default.pmc. To that end, the kill-useless-defaults branch
was created.
The first vtable removed was get_pointer(), which I feel is enough of
a change (and slight breakage) to require a merge into master before
further
Wasn't there talk recently of adding GC integration to profiling?
Would that be a use-case for a separate, runtime pluggable GC core? Or
would we rather put a lot of branching in the ordinary GC core to
support rarely used functionality? Hookable gc and pluggable GC seem
very similar to me.
On Mon
The default PMC, to which most PMCs delegate their unhandled vtables,
makes some odd choices in terms of what functionality it attempts to
provide versus giving up and throwing a "not implemented" exception.
Among the "implemented" vtables are get_pointer, freeze, thaw, visit,
and clone. default's
On Wed, Aug 17, 2011 at 7:01 AM, Christoph Otto wrote:
> Earlier today at YAPC::EU, jnthn mentioned a number of features and
> needs that would be especially helpful to Rakudo. I though I ought to
> relay those items. They are as follows.
>
> 1) Threading
> 2) Asynchronous I/O People have come
On Sun, Jul 17, 2011 at 7:22 PM, Kevin Polulak wrote:
> On Sat, Jul 16, 2011 at 10:28 PM, James E Keenan wrote:
>>
>> 8. What are the purposes of the top-level directories in the Parrot
>> distribution? Would they each benefit from short READMEs explaining that?
>
> I'm still not completely sure
On Sun, Jul 17, 2011 at 11:00 AM, Patrick R. Michaud wrote:
> On Sun, Jul 17, 2011 at 10:21:19AM +0200, Moritz Lenz wrote:
>>
>> Question to the Parrot developers: How could I implement DESTROY methods
>> in Rakudo? Is there any vtable I can override, or so? Note that such a
>> method might itself
#x27;hello', value: 1, test: [Function] }
> { hello: 'hello', value: 1, test: [Function] }
> { hello: 'hello', value: 1, test: [Function] }
>
> _
>
> On Wed, Jun 15, 2011 at 10:58 AM, Peter Lobsinger w
On Tue, Jun 14, 2011 at 8:57 AM, rohit jangid wrote:
> thanks lucian.
>
> My view on inheritance was that.
> 1) first an empty object is created and it prototype points to
> constructor's prototype .
> 2) this object is passed into the constructor function where it can be
> refrenced by "this"
> 3
On Sun, May 15, 2011 at 5:41 PM, Kevin Tew wrote:
> Byte strings, the former 't' NCI type, are as primitive a data type as int
> is for libraries written in C.
> I think some of Jonathan and Patrick extreme surprise is that we are making
> the extremely common use of C byte strings more laborious
On Fri, May 13, 2011 at 11:57 PM, Patrick R. Michaud wrote:
> On Fri, May 13, 2011 at 09:53:10PM -0400, Peter Lobsinger wrote:
>> On Fri, May 13, 2011 at 3:58 PM, Patrick R. Michaud
>> wrote:
>> > I also notice that according to api.yaml the UnManagedStruct type
>>
On Fri, May 13, 2011 at 9:54 PM, Will Coleda wrote:
> On Fri, May 13, 2011 at 9:44 PM, Peter Lobsinger wrote:
>> On Fri, May 13, 2011 at 1:45 PM, Will Coleda wrote:
>>> On Fri, May 13, 2011 at 10:21 AM, Peter Lobsinger
>>> wrote:
>>>> On Fri, May 13
On Fri, May 13, 2011 at 3:58 PM, Patrick R. Michaud wrote:
> I also notice that according to api.yaml the UnManagedStruct type
> is deprecated and eligible for removal in 3.4 (i.e., "now").
> Zavolaj uses that also, so in order to avoid another "surprise"
> we need details on the upgrade path for
On Fri, May 13, 2011 at 1:45 PM, Will Coleda wrote:
> On Fri, May 13, 2011 at 10:21 AM, Peter Lobsinger wrote:
>> On Fri, May 13, 2011 at 7:24 AM, Jonathan Worthington
>> wrote:
>>> Hi,
>>>
>>> The deprecated 't' parameter in NCI broke Zav
On Fri, May 13, 2011 at 10:29 AM, Carl Mäsak wrote:
> Jonathan (>>), Peter (>):
>>> It seems that the signatures for e.g. mysql database connection were
>>> removed, not updated! The deprecation notice doesn't provide anything that
>>> seems to help with our use case. Replacing t with S seems to l
On Fri, May 13, 2011 at 7:24 AM, Jonathan Worthington
wrote:
> Hi,
>
> The deprecated 't' parameter in NCI broke Zavolaj (the Perl 6 native call
> interface). This in turn broke various modules, including MiniDBI. Looking
> at:
>
> https://github.com/parrot/parrot/commit/75e2b4c94d602d3d7e8af4b679
On Mon, May 9, 2011 at 12:30 PM, Sam Vilain wrote:
> ABSTRACT:
>
> Perl’s history has seen two threading models; one shared-state model now
> dis-
> continued, and one heap-duplicating model with a very inefficient shared
> state ap-
> proach. There is also an Erlang-style threading library on CPA
d gc pool size are based (OS X 10.4
does not implement ASLR, so no worries there). Please run these
standalone and under make (by adding a make target that calls them).
Significant differences between make and standalone results might
indicate the root of the issue. Knowing these values
of NCI.
I would ask any Parrot developers with access to a PPC/Darwin (aka OS
X) machine to attempt to reproduce this bug. I welcome any and all
insights into this matter, especially what make (specifically GNU Make
3.80) might be doing to trigger the error.
Than
On Wed, Apr 27, 2011 at 8:15 AM, James E Keenan wrote:
>
> On Apr 26, 2011, at 7:34 PM, James E Keenan wrote:
>
>>
>>
>> I still have to see whether the problems on Darwin/PPC pasted last night
>> persist.
>>
>
> On Darwin/PPC, when I compile with cc=gcc ld=g++ link=g++, the build
> completes and
y-reference. This
binding has been updated to the new API and makes a good reference, in
my opinion.
> Cheers,
> Donald.
> On 26 April 2011 02:20, Peter Lobsinger wrote:
>>
>> The tt1931-nci-parameters-deprecation is feature complete and ready
>> for testing/merge.
>
.
No breakage in core is anticipated with this branch, nor is any
performance regression. Please test to confirm this is the case.
Baring any unforseen problems, I will be merging this branch in the
next couple of days.
Thanks,
Peter Lobsinger
___
http
On Sat, Apr 2, 2011 at 8:27 PM, Andrew Whitworth wrote:
> I'm not seeing that failure on my machine. Can you send me a copy of
> the failure report?
>
> --Andrew Whitworth
>
>
>
> On Sat, Apr 2, 2011 at 6:29 PM, Peter Lobsinger wrote:
>> I'm still seeing
I'm still seeing errors on t/examples/pod.t.
On Sat, Apr 2, 2011 at 1:31 PM, Andrew Whitworth wrote:
> I've fixed several problems in this branch (with help from plobsing++
> and others). I would like to get as much help testing and exercising
> this branch as possible. Problematic architectures
On Thu, Mar 24, 2011 at 6:51 PM, Ben Batha wrote:
> I was also interested in the Java compiler and had similar questions about
> starting resources. Specifically I was wondering what language was intended
> for the Java on Parrot project to be written in?
It is fairly open ended.
In terms of the
On Thu, Mar 24, 2011 at 6:45 PM, Kevin Polulak wrote:
> Hey guys,
>
> I am a student interested in working on Parrot's debugger for Google Summer
> of Code 2011. Some of you may already know me as soh_cah_toa #parrot. If you
> do, then you know that I've spent the last week gathering ideas and stu
wins over performance every time, so I am +1 for this
>> branch to merge.
>>
>> Duke
>>
>> On Fri, Mar 11, 2011 at 3:17 PM, Peter Lobsinger wrote:
>>> On Fri, Mar 11, 2011 at 5:57 PM, Jonathan "Duke" Leto
>>> wrote:
>>>> Howdy,
>&
On Mon, Mar 14, 2011 at 9:57 PM, James E Keenan wrote:
> Vasily Chekalkin wrote:
>>
>> Hello.
>>
>> On Mon, Mar 14, 2011 at 8:12 AM, Andy Dougherty
>> wrote:
>>>
>>> I don't know if this slowdown is expected or significant, but it's
>>> certainly quite noticeable.
>>
>> It's kind of "expected" du
mance every time, so I am +1 for this
>> branch to merge.
>>
>> Duke
>>
>> On Fri, Mar 11, 2011 at 3:17 PM, Peter Lobsinger wrote:
>>> On Fri, Mar 11, 2011 at 5:57 PM, Jonathan "Duke" Leto
>>> wrote:
>>>> Howdy,
>>>
concern and is unlikely to be affected
in any major way.
> Duke
>
> On Fri, Mar 11, 2011 at 2:35 PM, Peter Lobsinger wrote:
>> The pmc2c-multi-nativepccmethod branch changes the implementation of
>> MULTIs in .pmc files from NCI to NativePCCMethod. This means that
>> th
The pmc2c-multi-nativepccmethod branch changes the implementation of
MULTIs in .pmc files from NCI to NativePCCMethod. This means that
these now handle their own PCC, in stead of rellying on NCI thunks to
accomplish this. These can now be modified to access a more broad
range of PCC functionality.
Passing around pointers as ints is not advisable. We have pointer
wrapper PMC types for this. You can wrap a pointer by doing something
such as:
PMC *ptr_pmc = Parrot_pmc_new(interp, enum_class_Ptr);
VTABLE_set_pointer(interp, ptr_pmc, (void *)wb);
Sorry, I'm not sure what the embedding API e
On Wed, Feb 23, 2011 at 11:40 AM, Kevin Tew wrote:
> On 02/23/2011 09:34 AM, Peter Lobsinger wrote:
>>
>> On Wed, Feb 23, 2011 at 11:09 AM, wrote:
>>>
>>> Branch: refs/heads/master
>>> Home: https://github.com/parrot/parrot
>>>
&
On Wed, Feb 23, 2011 at 11:09 AM, wrote:
> Branch: refs/heads/master
> Home: https://github.com/parrot/parrot
>
> Commit: 97e42dfe4a81c1c113138843ab31822eced16820
>
> https://github.com/parrot/parrot/commit/97e42dfe4a81c1c113138843ab31822eced16820
> Author: Kevin Tew
> Date: 2011-02-23 (
The 'ptrbuf' branch implements PMCs for low-level buffer access which
separate the representation from the pointers.
The immediate goal of this branch is to provide a replacement for
Pointer, UnManagedStruct, and ManagedStruct, which have been described
in the past as hard and/or inconvenient to u
I have re-enabled optimized register access for non-gcables in
5829c74. This mitigates some of the costs.
However, gcable register access is far from optimal. We have
annotations in the ops files to determine whether a register will be
written or not. A read-only GCable register access (by far the
There has been a marked decrease in performance on optimized builds
for some uses of Parrot since the merge of the generational_gc branch.
These stem from f14c1a62 ("Temporary workaround to enable write
barriering of CallContexts"). In brief, optimized access to registers
has been disabled.
2 case
2011/2/6 George Magklaras :
> On 02/06/2011 09:14 PM, Peter Lobsinger wrote:
>>
>> First off, no I am not swearing at you. Ωη;)XD, pronounced
>> ohm-eta-wink-kzd or "ometa winxed", is a port of OMeta[1] to Parrot
>> using Winxed[2] as a host language.
>>
First off, no I am not swearing at you. Ωη;)XD, pronounced
ohm-eta-wink-kzd or "ometa winxed", is a port of OMeta[1] to Parrot
using Winxed[2] as a host language.
After 2 months of on-and-off hacking, it is my pleasure to announce
that Ωη;)XD is of beta quality and is ready for use by early adopte
On Sun, Feb 6, 2011 at 9:44 AM, Patrick R. Michaud wrote:
> Bacek++ fixed TT #1994 so that .INTERPINFO_ACTIVE_PMCS works again
> (thanks!); while playing with it I noticed that creating the first
> instance of a PMC type such as Integer or Float results in the
> creation of 38 extra PMCs somewhere
On Sun, Feb 6, 2011 at 8:32 AM, Shockwave wrote:
> Hello, All.
>
> I have a couple of questions regarding method invocation with the new
> embedding API.
>
> I'm not sure of the correct way of calling a class method. I've found a
> unit-test that made use of the API function Parrot_api_pmc_invoke(
On Tue, Feb 1, 2011 at 7:43 PM, Mike Heise wrote:
> Isn't Winxed already roughly JS with minimal changes to access Parrot
> internals?
This is a common misconception that I'd like to be cleared up if we
are to seriously consider Winxed as a language for this purpose. It is
superficially similar
On Mon, Jan 31, 2011 at 9:56 AM, Patrick R. Michaud wrote:
> 3. Serialization. The major item that makes Rakudo startup so slow
> is that we have to do so much initialization at startup to get
> Rakudo's type system and setting in place.
>There's not a good
> way in Parrot to reliab
On Mon, Jan 31, 2011 at 9:30 AM, jerry gay wrote:
> On Sat, Jan 29, 2011 at 18:51, Bruce Gray wrote:
>> Not-Quite-NQP?
>> Something similar to NQP could be created, to forever be oriented to
>> Parrot's own needs. Particle mentioned forking the current NQP.
>>
> my understanding of patrick's
The annotations-tree branch changes the way we store annotations to
make these more space-efficient and faster to look up. Whereas before,
to lookup annotations required multiple linear scans of various arrays
within the annotations table, now entries are contained in ordered
lists per-annotation-k
On Mon, Jan 24, 2011 at 11:49 AM, Andrew Whitworth
wrote:
> The whiteknight/imcc_interfaces branch is ready for general testing.
> It implements a series of cleanups for the IMCC interface functions,
> and should preserve most existing functionality. These changes are the
> basis for additional wo
The pbc-backref branch is complete in terms of features and passes
fulltest and rakudo-spectest. It is my intent to merge this
immediately after the release. This is well encapsulated from nearly
everything, so there are no expected difficulties, however, please run
whatever tests you feel are appr
The purpose platform-encoding branch is to lay some groundwork for
managing encodings on different platforms.
The underlying assumption used is that a platform uses 1 encoding for
its various interfaces (argv, paths, environment variables, etc). A
new encoding alias, "platform", has been added to
On Sat, Jan 8, 2011 at 12:03 PM, jerry gay wrote:
> On Fri, Jan 7, 2011 at 20:58, Peter Lobsinger wrote:
>> We currently have 3 (openbsd, windows, everybody else)
>> platform-specific implementations of code for allocating,
>> reallocating, and freeing executable memory pa
We currently have 3 (openbsd, windows, everybody else)
platform-specific implementations of code for allocating,
reallocating, and freeing executable memory pages. This was used at
one time to implement the JIT. I propose we remove this code because:
(1) it is currently dead code
(2) candidate
On Fri, Jan 7, 2011 at 9:45 AM, Andrew Whitworth wrote:
> 1a) For that matter, we could replace get_params with a handful of new
> ops: get_pmc, get_pmc_slurpy, get_x_named, get_x_optional, etc. Each
> one would make a single transaction with the signature object. In this
> case, fill_params evapo
On Sun, Jan 2, 2011 at 9:13 PM, Andrew Whitworth wrote:
> On Sun, Jan 2, 2011 at 5:25 PM, Peter Lobsinger wrote:
>> The hit assertion is for sig_str, which is legitimate. Every NCI
>> function *must* have a signature in order to be able to determine how
>> to map PCC to th
On Sun, Jan 2, 2011 at 4:56 PM, Nolan L wrote:
> On Sun, Jan 2, 2011 at 4:40 PM, Peter Lobsinger wrote:
>> If you provide the script you've run to hit these assertions, we can get
>> started on fixing this problem. Also, patches welcome.
> The following PIR segment
On Sun, Jan 2, 2011 at 2:08 AM, Nolan L wrote:
> Whilst going through the NCI PMC for the purpose of increasing test
> coverage, I noticed inconsistent behavior of many of the VTABLE
> functions within. While some returned pointers to nci_info->orig_func,
> others operated on nci_info->func, creat
The encapsulate-main branch moves tracking of :main-tagged subs from
the subs themselves to packfiles (which should really be taking care
of this kind of thing). At the same time, it tackles TT #1704, which
requires a :main sub (no more automagic
first-encountered-sub-is-main).
At this point, it p
On Thu, Dec 16, 2010 at 8:59 AM, Will Coleda wrote:
> On Thu, Dec 16, 2010 at 8:44 AM, Peter Lobsinger wrote:
>> On Wed, Dec 15, 2010 at 7:13 PM, James E Keenan wrote:
>>> $ ll t/include/
>>> total 1
>>> -rw-r--r-- 1 jimk jimk 760 Dec 14 20:30 fp_equa
On Wed, Dec 15, 2010 at 7:13 PM, James E Keenan wrote:
> $ ll t/include/
> total 1
> -rw-r--r-- 1 jimk jimk 760 Dec 14 20:30 fp_equality.t
>
> This directory in our repository holds a single test file. From the
> documentation:
>
> t/include/fp_equality.t - Test runtime/parrot/include/fp_equalit
On Fri, Dec 10, 2010 at 4:39 PM, Richard Hainsworth
wrote:
> On 12/09/10 21:43, yary wrote:
>>
>> I see a pattern - the libs not found have a version number. They
>> should also be removed (along with the .so), let the linker determine
>> the version. How it will decide between 4.7 and 4.8 when yo
On Sun, Dec 5, 2010 at 6:50 AM, Richard Hainsworth wrote:
> The examples/ directory needs some attention as examples in some directories
> dont work out of the box.
>
> I tried examples in examples/sdl, examples/opengl, and examples/tcl
Many of the examples are extremely old at this point and rec
On Tue, Nov 30, 2010 at 5:35 PM, Andy Dougherty wrote:
> Rakudo won't build with the current parrot master. The first error
> message is about the function 'Parrot_get_ctx_HLL_namespace'. Were some
> functions renamed? If so, the old names should still be kept around as
> wrappers for the new n
On Tue, Nov 23, 2010 at 9:27 PM, Jonathan Leto wrote:
> Howdy,
>> * parrot in its current form is hardly "small". tweaks are available
>> to pair it down significantly, but they aren't the default, so it
>> would be some work to find and use these optimally.
>
> Define "small".
I'd say the low-e
You may be able to do this in parrot with a few contortions. But
parrot may not be the best fit because:
* parrot in its current form is hardly "small". tweaks are available
to pair it down significantly, but they aren't the default, so it
would be some work to find and use these optimally.
* par
The codestring-deprecation-prep branch removes all dependancies on
CodeString as well as the CodeString PMC itself. It is ready for
merge.
Instructions on how to update after the removal are on the wiki.
Any objections to merging this into master?
___
h
Looking at examples of how to compile and link against parrot
(examples/embed and plparrot), it appears to me that parrot_config is
answering questions at the wrong level. In stead of questions like
"What flags do I need to use to compile a C file which #includes
parrot headers?", "What linker flag
On Wed, Nov 10, 2010 at 12:28 AM, Peter Lobsinger wrote:
> The gsoc_nci branch is at a point where it should be mergeable. Please
> test it on any platforms you happen to care about. 'make test' should
> exercise the full functionality, but other variants couldn't
On Wed, Nov 10, 2010 at 11:54 AM, Andy Dougherty wrote:
> On Wed, 10 Nov 2010, Peter Lobsinger wrote:
>
>> On Wed, Nov 10, 2010 at 9:22 AM, Andy Dougherty
>> wrote:
>> > On Wed, 10 Nov 2010, Peter Lobsinger wrote:
>> >
>> >> The gsoc_nci branch is
On Wed, Nov 10, 2010 at 9:22 AM, Andy Dougherty wrote:
> On Wed, 10 Nov 2010, Peter Lobsinger wrote:
>
>> The gsoc_nci branch is at a point where it should be mergeable. Please
>> test it on any platforms you happen to care about. 'make test' should
>> exercise
e to pull
the values out of parrot_config and generate it themselves. It is
likely to be disused, fall out of date, and generally be wrong; just
like the current situation.
> Am Mittwoch, den 10.11.2010, 05:26 +0100 schrieb Peter Lobsinger:
>> PDD30 and pkg-config don't work well togeth
The gsoc_nci branch is at a point where it should be mergeable. Please
test it on any platforms you happen to care about. 'make test' should
exercise the full functionality, but other variants couldn't hurt
either.
Test configurations of interest are (in more or less descending order
of importance
PDD30 and pkg-config don't work well together leading to the problems
described in TT #1842. In my opinion, the purpose of pkg-config
doesn't really agree with the goal of multiple installed versions.
Further, it is not likely to be installed on many systems we are
targeting.
parrot_config should
On Sun, Oct 10, 2010 at 12:49 PM, Jonathan Leto wrote:
> Howdy,
>
> +1 to lightening our load, so we can deploy to embedded/mobile devices.
Remember that on a number of smaller devices, shared libraries are not
possible or at the very least undesirable. But then, we really should
have a cross-com
On Tue, Oct 5, 2010 at 8:30 AM, James E Keenan wrote:
> Fellow Parrot developes,
>
> In its discussion of adding new components to the Parrot configuration
> process, docs/configuration.pod contains this language:
>
> "It is strongly recommended that you file a Trac ticket in which you state
> the
On Tue, Sep 21, 2010 at 4:34 PM, Paul Wolneykien
wrote:
>
>
> 21.09.2010 03:11, NotFound writes:
>>>
>>> * The problem *
>>>
>>> Extracting a representative set of dependencies using the described
>>> method is only possible when a high-level language compiler that
>>> produces a code of the mod
On Mon, Sep 20, 2010 at 6:27 PM, Paul Wolneykien
wrote:
> * The module scan tool *
>
> As far as I understand the system of Parrot, a source code module of
> any program in any language is finally translated into a bytecode module
> (i.e. *.pbc) that is then run by the Parrot interpreter (VM). Ea
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
On Fri, Sep 17, 2010 at 3:55 PM, Nick Wellnhofer wrote:
> On 17/09/10 19:34, Peter Lobsinger wrote:
>>
>> I think we need both a deprecation notice and stub implementations of
>> these macros by 2.9. Being able to assign simply by using 'x = y' is
>> pretty
On Fri, Sep 17, 2010 at 11:43 AM, Andrew Whitworth
wrote:
> On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger wrote:
>> But more to the point, they are insufficient for handling aggregates.
>> If a PMC cointaining ATTR isn't a simple PMC*, but something more
>> com
On Fri, Sep 17, 2010 at 8:49 AM, kjstol wrote:
> On Fri, Sep 17, 2010 at 6:54 AM, Peter Lobsinger wrote:
>> pirc:
>> * incompatibilities with imcc (if any) likely need deprecations
>> * stalled, so these incompatibilities are unknown at the moment
>
> I could point
On Fri, Sep 17, 2010 at 8:12 AM, Andrew Whitworth wrote:
> On Fri, Sep 17, 2010 at 1:54 AM, Peter Lobsinger wrote:
>> GC:
>> * Generational:
>> * requires barriers to handle bookkeeping at reference creation
>> * existing object attribute access barriers are
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 in time to allow our 3.0 goals to be met, so we
need to start think
-1 to adding such features to core without any prior demand from users
(none that I've heard anyways).
On Thu, Sep 16, 2010 at 1:35 PM, Paul C. Anagnostopoulos
wrote:
> Folks,
>
> We have a full compliment of trig, inverse trig, and hyperbolic operations,
> except for:
>
> acot
> coth
> acsc
> cs
-- Forwarded message --
From: Peter Lobsinger
Date: Thu, Sep 16, 2010 at 3:29 AM
Subject: Re: Deprecate Buffers.
To: Vasily Chekalkin
Why do they even need deprecation? Are they user visible somehow?
On Wed, Sep 15, 2010 at 5:12 AM, Vasily Chekalkin wrote:
> He
On Wed, Aug 25, 2010 at 4:56 PM, chromatic wrote:
> On Tuesday 24 August 2010 at 10:14, plobsing wrote:
>
>> Author: plobsing
>> Date: Tue Aug 24 17:14:54 2010
>> New Revision: 48634
>> URL: https://trac.parrot.org/parrot/changeset/48634
>>
>> Log:
>> inline undocumented, used-once static functio
It is dead code, the remainder of the old JIT's frame-builder. It
should be eliminated. I will eventually if nobody beats me to it.
On Mon, Aug 16, 2010 at 7:35 PM, Andy Lester wrote:
> I'm about to go headerize src/frame_builder.[ch], but then I can't find where
> it's used anywhere. Is it? I
The dynop_mapping branch is an attempt to deal with the dynop
numbering issue when loading PBCs that use different dynoplibs in
possibly different orders. It is currently in working condition,
albeit with a few snags:
* There is no longer a global table of opcodes, so OpLib needs
rethinking. Maybe
On Tue, Aug 3, 2010 at 6:11 AM, Jonathan Worthington wrote:
> On 02/08/2010 08:05, Peter Lobsinger wrote:
>>
>> On Fri, Jul 30, 2010 at 8:08 PM, Jonathan Worthington
>> wrote:
>>
>>>
>>> Here's one critical thing, however. This is _not_ about
On Fri, Jul 30, 2010 at 8:08 PM, Jonathan Worthington
wrote:
> chromatic wrote:
>>
>> Rakudo and other HLLs could greatly benefit from Parrot sorting out the
>> "How and when do I declare a class?" mess. The best way I can see for us to
>> help them is to ease the requirement that all classes nee
On Wed, Jul 28, 2010 at 6:02 PM, chromatic wrote:
> Rakudo and other HLLs could greatly benefit from Parrot sorting out the "How
> and when do I declare a class?" mess. The best way I can see for us to help
> them is to ease the requirement that all classes need declaration in :load
> :init subs
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 simple, inefficient
>> way (every
On Sun, Jun 27, 2010 at 4:33 PM, Andrew Whitworth wrote:
> Doing it in IMCC is intractable I think. It's probably okay if basic
> PIR doesn't get too fancy with register allocation, though there's no
> reason why it shouldn't be added in to POST. Do you think it should be
> part of normal POST ope
On Thu, Jun 3, 2010 at 4:57 PM, Vasily Chekalkin wrote:
> Hello.
>
> After recent digging into GC guts, work on immutable strings, masak++
> work on strings building I would like to propose next changes in
> parrot core.
>
> 1. Remove "buffers" (which is string-like mutables). They adds a lot
> of
sociate opcode tables per bytecode
segment or per thread in stead of keeping them in what is effectively
a global right now (which is why a number of things are in varying
states of fail).
> just my 2c.
> kjs
>
> On Mon, May 31, 2010 at 11:50 AM, Patrick R. Michaud
> wrote:
>>
Comments? Suggestions of rarely used const-variant ops to kill?
Peter Lobsinger
___
http://lists.parrot.org/mailman/listinfo/parrot-dev
On Sun, May 30, 2010 at 12:01 AM, Stefan O'Rear wrote:
> On Sat, May 29, 2010 at 11:38:58PM -0700, Peter Lobsinger wrote:
>> 3) Have a separate ops table for every bytecode segment, switch tables
>
> 3a) The core ops become merely a preloaded dynop table. Since you only
>
. Pro: one ops table, small per-segment
cost. Con: much copying.
All of these options have good and bad attributes, none of them jump
out at me as the superior solution. Ideas?
Peter Lobsinger
___
http://lists.parrot.org/mailman/listinfo/parrot-dev
-- Forwarded message --
From: Peter Lobsinger
Date: Wed, May 26, 2010 at 12:01 AM
Subject: Re: GSoC NCI Purposed Improvements
To: Geoffrey Broadwell
On Tue, May 25, 2010 at 4:00 PM, Geoffrey Broadwell wrote:
> On Tue, 2010-05-25 at 13:43 -0700, jerry gay wrote:
>> &g
, readline, printerr, seek, tell, peek, open,
close, get/set std in/out/err
+ set.ops: clear[insp], set[insp]_ind, exchange
+ math.ops: cmod, trancendentals
+ sys.ops: all except for spawnw, err, time, and sleep
Peter Lobsinger
___
http://lists.parrot.o
1 - 100 of 134 matches
Mail list logo
