> Not to be a pest, but the "open" opcode becoming a dynop is what broke
> PL/Parrot recently. There is nothing wrong with open being a dynop per
> se, but a long standing bug with dynops that rarely got tickled is now
> much more important. If that bug was fixed, "open" being a dynop would
> be al
Howdy,
On Tue, Jun 1, 2010 at 4:22 PM, Will Coleda wrote:
> My vote is to resurrect the getstd* opcodes.
>
> Since the general consensus seems to be "doesn't matter", let's move
> these back.
>
Not to be a pest, but the "open" opcode becoming a dynop is what broke
PL/Parrot recently. There is no
My vote is to resurrect the getstd* opcodes.
Since the general consensus seems to be "doesn't matter", let's move
these back.
On Tue, Jun 1, 2010 at 5:46 PM, Andrew Whitworth wrote:
> The printerr opcode disappearing would be fine if the getstderr opcode
> hadn't disappeared. What we need is a g
> The printerr opcode disappearing would be fine if the getstderr opcode
> hadn't disappeared. What we need is a good, reliable way to get
> FileHandle PMCs for STDIN, STDOUT, and STDERR. Once we have a handle,
> the print_p_s opcode works just fine for almost all purposes. There is
> an stdhandle
The printerr opcode disappearing would be fine if the getstderr opcode
hadn't disappeared. What we need is a good, reliable way to get
FileHandle PMCs for STDIN, STDOUT, and STDERR. Once we have a handle,
the print_p_s opcode works just fine for almost all purposes. There is
an stdhandle method on
On Tue, Jun 01, 2010 at 09:41:19PM +0200, NotFound wrote:
> > it would even be worthwhile to step back and re-think whether all the ops
> > that were moved out of core really should have been moved. If every
> > non-trivial program now needs to load several dynop libraries, is there
> > really any
> Or, given the number and complexity of problems that have ensued, perhaps
> it would even be worthwhile to step back and re-think whether all the ops
> that were moved out of core really should have been moved. If every
> non-trivial program now needs to load several dynop libraries, is there
>
On Tue, 1 Jun 2010, Will Coleda wrote:
> We've had some ping pong'ing code of late regarding the dynop
> libraries as they've been moved in and out of 'make corevm'
>
> If so, we should actually test all of them as part of core, and not
> just the ones that happen to be in 'corevm' after ops mass
On Tue, Jun 1, 2010 at 1:41 PM, Michael Hind wrote:
> We really need to consider what constitutes the "core" of parrot.
>
> This is what is tested by make corevm/make coretest
>
> Extensions are generally not considered part of the "core".
>
> As regards, dynops and dynpmcs, I would probably not c
We really need to consider what constitutes the "core" of parrot.
This is what is tested by make corevm/make coretest
Extensions are generally not considered part of the "core".
As regards, dynops and dynpmcs, I would probably not consider them part of
"core", but could go either way.
The chang
> -Original Message-
> From: parrot-dev-boun...@lists.parrot.org [mailto:parrot-dev-
> boun...@lists.parrot.org] On Behalf Of Will Coleda
> Sent: Tuesday, June 01, 2010 09:39
> To: parrot-dev@lists.parrot.org
> Subject: dynoplibs in core or no?
>
> We've had some ping pong'ing code of late
We've had some ping pong'ing code of late regarding the dynop
libraries as they've been moved in and out of 'make corevm'
If so, we should actually test all of them as part of core, and not
just the ones that happen to be in 'corevm' after ops massacre.
If not, we should not build them as part of
On Tue, Jun 01, 2010 at 07:58:59AM -0700, chromatic wrote:
> Even so, getting the optimization language ideal (or at least, correct) is
> beyond what I expect from Tyler as part of his project. If his design works
> out well, we can modify that language as necessary; it's just matching nodes
>
> The idea (which I may not have conveyed sufficiently well), is that we
> eliminate rarely-used or even nonsensical constant variants of ops.
> That is, get a constant gain at the expense of a cost to rare use
> cases.
Works for me, as long as we recognize that we're going to maintain
a special-c
On Monday 31 May 2010 at 07:54, Patrick R wrote:
> Ah, more directly (again I'm just brainstorming with some P6 syntax):
>
> class FoldAddition {
> multi method fold(PAST::Op $/ where $/.pirop eq 'add'
> and $0 ~~ PAST::Val
>
On Mon, May 31, 2010 at 12:11 PM, kjstol wrote:
> 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 Sugals
16 matches
Mail list logo
