__color__,__group__,ticket,summary,component,version,owner,status,created,_changetime,_description,_reporter 3, Release,777,.HLL should not case-mangle its arg,hll_interop,trunk,,new,2009-06-19T17:16:44Z,2011-01-11T10:21:22Z,"In many cases, .HLL 'Donut' is the same as .HLL 'donut'; however, in some cases (e.g. ParrotInterpreter.hll_map()), it's not. I recommend that to avoid any potential for confusion, we remove any case mangling and treat the HLL exactly specified in the directive. If we get consensus on this, we can add a deprecation notice for 1.4 and change it immediately after release. ",coke 3, Release,1500,API to tell which opcode group an opcode is in,core,master,whiteknight,new,2010-03-06T03:57:05Z,2011-10-24T14:58:11Z,"I am currently hacking on PL/Parrot and one of the very important features that we need is disallowing certain operations, most notably file I/O. The motivation for this is that you do not want a stored procedure written in PIR to be able to modify the database via disk operations. I talked with chromatic in #parrot about needing some security subsystem features and he agreed that we need an API for telling if an opcode is in a particular opcode group. This is talked about in PDD18 if you want to get the full background. For instance, take the open opcode: {{{ inline op open(out PMC, in STR, in STR) :filesys_open { /* etc... */ } }}} It is defined to be in the ""filesys_open"" opcode group. Currently there is no way to tell if a certain opcode is in a given group. The information does not seem to make it into op_info_t, but it is in lib/Parrot/OpLib/core.pm . I propose a public C API that will consist of at least these three functions: {{{ Parrot_sec_opcode_is_in_group(string opcode_name, string group_name) }}} This function would take an opcode name and opcode group name as argument and return true if the opcode is in the group, false otherwise. {{{ Parrot_sec_opcodes_in_group(string opcode_group) }}} This function takes a string argument of an opcode group name and returns a ResizableStringArray containing all opcodes in that group. {{{ Parrot_sec_groups_containing_opcode(string opcode_name) }}} This function takes a string argument of an opcode name and returns a ResizableStringArray listing all groups that contain the given opcode name. Once an API in C is available to accomplish these things, then it should be straight forward to access this information from PIR. ",dukeleto 3, Release,1825,How To Utilize The GCC Compile Farm,build,2.8.0,dukeleto,new,2010-10-13T00:55:18Z,2010-10-20T17:27:39Z,"Parrot now has access to the GCC Compile Farm, graciously hosted by the Free Software France organization. We need to figure out how best to use it i.e. installing BuildBot, TapTinder, smokers and benchmarkers across different configurations of Parrot, such as ICU/GMP/optimized/etc. Here are some links to a presentation about the Compile Farm: https://mail.gna.org/public/gcc-cfarm-users/2010-07/msg00025.html This is the main wiki page: http://gcc.gnu.org/wiki/CompileFarm",dukeleto 4, Release,649,Should parrot_config report separate inst_ and build variables?,install,1.1.0,whiteknight,new,2009-05-08T12:42:22Z,2010-11-24T03:16:32Z,"Some discussion of this topic is on the parrot-dev mailling list, starting at: [http://lists.parrot.org/pipermail/parrot-dev/2009-April/002158.html] (The thread continues into the beginning of the next month, here at [http://lists.parrot.org/pipermail/parrot-dev/2009-May/002162.html] and [http://lists.parrot.org/pipermail/parrot-dev/2009-May/002172.html].) I have tentatively assigned this ticket a milestone of 1.4, the next ""supported"" release. If indeed version 1.4 is to be packaged and widely distributed, then it would be nice to clear up such issues beforehand.",doughera 4, Release,707,[RFC] StringHandle interface,core,1.2.0,NotFound,assigned,2009-05-26T15:30:06Z,2011-01-15T13:11:22Z,"There some points in the StringHandle pmc that needs clarification: - Read/Write mode: Must it works the same as FileHandle? Several tests use read methods in a StringHanlde opened for writing. IMO will be better to have methods to get/set the string content, use the get_string/set_string/native vtable functions, or both, and have the read methods throw exceptions when not opened for read. - Mode when reopened without second argument: must use the flags used on the previous open, or use the 'r' default? Several tests assume the second, but works only because of the first issue. ",NotFound 4, Release,774,deprecate PMC multiple inheritance,pmc2c,1.2.0,cotto,new,2009-06-18T18:23:06Z,2010-12-02T09:13:49Z,"I'd like to deprecate the behavior of pmc2c which allows C-level PMC multiple inheritance. The behavior needs supporting code which isn't properly tested in Parrot's test suite. Any modification to pmc2c that deals with a PMC's parents also needs to take this behavior into account or risk causing failures in HLLs which may not be reported for some time. Currently the only language I know of that uses MI is Lua (partcl no longer needs it), and coke claims that MI doesn't allow anything that can't be done in another way. I've asked fperrad about how much work it would be for him to avoid MI. If it's a big deal for him (or any other HLL devs) I don't mind continuing to support it. Once I hear back from fperrad and don't get any other objections, I'll add a proper deprecation notice so this feature can be removed post-1.4.",cotto 4, Release,905,[RFC] Deprecate Eval PMC,none,1.4.0,,new,2009-08-07T03:55:51Z,2010-09-11T16:11:24Z,"The result of dynamically compiling a string of source code should be an ordinary Sub or Packfile object, not a custom Eval object. This ticket was split out from TT #448.",allison 4, Release,1033,no args checking for a sub without params,imcc,trunk,,new,2009-09-21T04:07:54Z,2011-08-27T16:54:14Z,"Originally reported in [http://rt.perl.org/rt3/Ticket/Display.html?id=39844 RT]. If no .params are given, no args checking is done on sub invocation. From the original: {{{ On Sat Jul 15 23:29:10 2006, mdiep wrote: > I expect this to die with a ""too many args"" error, but it doesn't -- > it prints ""ok"": > > .sub main :main > test(""foo"", ""bar"") > end > .end > > .sub test > print ""ok\n"" > .return() > .end > > -- > Matt Diephouse > }}} 2 sample patches to achieve this (both of which are declared to fail) are attached to the original ticket. Neither apply cleanly to trunk. There is a question, however, as to whether or not the existing behavior is desirable - should we always check args? should we always check except for :main? (should we check for :main too and suggest that the programmer use .param args :slurpy to avoid any issues?) There's a test already committed in t/op/calling.t",coke 4, Release,1156,add_sub should append to a MultSub,none,1.6.0,,new,2009-10-28T13:02:27Z,2009-10-28T13:02:27Z,"add_sub can add a Sub and a MultiSub to a NameSpace. However, if we add_sub again with the same name, it does not append the sub to the existing MultiSub (and does not combine with an existing Sub to form a new MultiSub). We need to determine what, if anything, needs to be done here. This comes from RT #55308",whiteknight 4, Release,1165,need ability to dispatch to parent's method or vtable from PIR,none,,allison,new,2009-10-30T17:25:29Z,2011-02-14T01:58:17Z,"If you write a class in PIR, you can access certain ancestral methods/vtables by getting the 'proxy' attribute for that ancestor, with two big limitations. you need to know the name of the ancestor that implements the vtable (this isn't always your direct parent.) that ancestor MUST be a PMC (not another class.) Since there is no generic mechanism to invoke a vtable by name, we should probably continue to use a proxy object to access this functionality. perhaps: {{{ # INT values only! .sub set_pmc_keyed :vtable .param pmc key .param pmc value $I0 = value .local pmc proxy proxy = get_proxy self proxy[key] = $I0 .end }}} Bikeshed away. Tcl needs this or something like it to fully implement the trace builtin. (which basically lets us run code before and after each vtable access.)",coke 4, Release,1188,[RFC] Modify build directories to more closely match the install directories,build,1.7.0,,new,2009-11-03T00:50:37Z,2011-02-25T03:16:24Z,"To simplify building a language from a build tree or install tree, change the build directories to more closely match the install directories. This would mean standardizing on lib/ Holds the compiled libparrot. Holds what's currently in runtime/* as subdirectories under lib/parrot/. Holds what's currently in lib/ (Perl modules) as subdirectories under lib/parrot/tools. bin/ Holds the compiled binaries for parrot, parrot_config, parrot_debugger, etc. src/ Holds C source files, same as now. Add a 'parrot/' subdirectory to be the same as include/ and lib/ (either all should keep the subdirectory, or none should). include/ Holds C header files, same as now. (The current blib/ directory just goes away.)",allison 4, Release,1190,Replace .globalconst/.const directives by .const/.localconst (respectively),core,trunk,,new,2009-11-03T16:01:44Z,2011-07-04T09:16:59Z,"This ticket replaces RT57634. hi, in PIR you can use the .globalconst directive in a sub to define a constant that is globally accessible. Likewise, you can use the .const directive in a sub that is local to that sub. .sub foo .globalconst int answer = 42 .const num PI = 3.14 .end answer in this case is globally accessible (in any other sub, that is parsed AFTER the foo subroutine, I should note) PI in this case is only accessible in this subroutine foo. However, I question the need for .globalconst, as the .const directive can also be used /outside/ of a subroutine, like so: .const int answer = 42 Therefore, the .globalconst directive seems to be superfluous; why have 2 directives that do the same thing; if a .globalconst is accessible globally anyway, there's no need to define it WITHIN a sub. Therefore, my proposal is to remove the .globalconst directive; whenever you need to have a global const, use .const outside of a subroutine. whenever you need to have a local const (in a sub), use .const inside a subroutine. comments welcome, kjs ",kjs 4, Release,1196,'parrot foo' automatically finds and invokes foo.pbc,none,,,new,2009-11-05T05:26:56Z,2011-02-25T03:27:02Z,"I just recently committed examples/sdl/blue_rect.pl as an example of exercising the SDL library using NQP. At the beginning of the file the instructions read: To run this file, execute the following command from the Parrot directory: $ ./parrot compilers/nqp/nqp.pbc examples/sdl/blue_rect.pl Typing in that pathname is a bit of a pain -- what I'd really like to be able to say is $ ./parrot nqp examples/sdl/blue_rect.pl and then since parrot can't immediately find anything called 'nqp' to execute, it looks for nqp.pbc in a standard location or locations and invokes that. Similarly $ ./parrot perl6 blue_rect.pl $ ./parrot tgc --output=gen.pir PASTGrammar.tg $ ./parrot abc $ ./parrot tcl xyz.tcl $ ./parrot pynie hello.py etc. Before we get too far, let me point out what I'm *not* asking for. Specifically, I'm *not* asking for parrot to automatically select an appropriate compiler based on a file's signature or magic, as discussed in RT#32374. In other words, I'm *not* asking that $ ./parrot examples/sdl/blue_rect.pl be able to automatically determine an appropriate compiler and invoke it on the script. While this is a very worthy and important goal, at the moment there seem to be so many issues around ""how does Parrot register compilers and figure out which one to use"" that I fear it will be a while before this gets implemented. I want something sooner than that. I'm also explicitly *not* asking to try to handle or resolve things based on Unix shebang lines, so that a file starting with #!/path/to/parrot nqp will automatically be executed with nqp. Again, it's something we will eventually want to consider, but given the vagaries of dealing with shebangs in so many different languages and platforms it's not what I'm aiming to get from this ticket. All I'm really looking is to be able to place the .pbc file for a compiler or other application into a standard location where it can be invoked from Parrot without having to give a complete path to the .pbc file. This could also have the benefit of simplifying Makefiles as well. For example, when I moved nqp from languages/ to compilers/ , I had to change the Makefile from $(PARROT) $(PARROT)/languages/nqp/nqp.pbc .... to $(PARROT) $(PARROT)/compilers/nqp/nqp.pbc ... While it was easy to do for this one case -- imagine if we had 10 or 20 applications that were using nqp as part of the build process. With the approach proposed here, the Makefile can have $(PARROT) nqp ... and it all just works. I would also be willing to accept an option-based version of this, such as (pick an appropriate option name or letter): $ ./parrot --prog=nqp blue_rect.pl Comments, suggestions, and (most importantly) implementations welcomed. Thanks, Pm",pmichaud 4, Release,1212,".eof returns false if last read call read the last byte of the file, but not beyond",core,,cotto,new,2009-11-05T17:37:27Z,2011-02-25T23:38:54Z,"Hi, It seems that the .eof() method on file handles can sometimes return true even if there is nothing more to read. This occurs when you have read upto the last byte of a file (e.g. when a readline reads up to the end of a newline, and that newline is the last thing in the file), but not beyond (which seems to be what causes the EOF flag to be set). I'm thinking this is the wrong behaviour? Thoughts and fixes welcome! Jonathan",jonathan 4, Release,1339,document all control exception types.,docs,1.8.0,,new,2009-11-29T02:37:43Z,2010-06-13T04:04:10Z,"These were meant to correspond to HLL flow control, like tcl's [break] and [continue], but it seems that CONTROL_LOOP_NEXT and CONTROL_LOOP_LAST were added as well (and those are in use by NQP, etc.). I don't particularly care which pair we keep, but having both sets is wrong.",coke 4, Release,1352,[RFC]: Realtime garbage collector for RTEMS,GC,1.8.0,,new,2009-12-03T08:20:31Z,2011-03-27T14:42:05Z," Parrot works on RTEMS. I am not sure how our garbage collector interacts with the real-time-ness of RTEMS, though. It probably needs to be shut off currently (parrot -G), to retain realtime characteristics. I have been doing research on realtime gc algorithms, there are a few implemented on the JVM, JeRTY VM and Jikes RVM. The ""Tortured History of Real-Time Garbage Collectors"" also seems like an interesting read. http://leto.net/dukeleto.pl/2009/11/realtime-embedded-parrots.html http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2901.pdf http://www.computer.org/portal/web/csdl/doi/10.1109/ISORC.2005.45 http://www.research.ibm.com/people/d/dfb/papers/Bacon03Realtime.pdf http://www.cs.wustl.edu/~mdeters/doc/slides/rtgc-history.pdf Any changes to the GC API should take into account that a realtime GC algorithm should be possible. ",dukeleto 4, Release,1356,[TODO] add method FixedStringArray.sort(),core,master,whiteknight,assigned,2009-12-03T17:54:22Z,2011-05-26T23:54:21Z,"Add the method sort in the FixedStringArray PMC. Currently, the method sort is only implemented in FixedPMCArray (and inherited by ResizablePMCArray). This method uses the C function Parrot_quicksort (in src/utils.c) which handles only PMC and not STRING.",fperrad 4, Release,1359,[RFC] Merge freeze/thaw with PBC,core,1.8.0,plobsing,new,2009-12-05T02:13:29Z,2010-01-25T23:21:34Z,"= Problems = freeze/thaw and PBC are already inter-related: * PBC uses freeze/thaw for constants * freeze/thaw uses PBC's low level binary IO abstraction freeze/thaw currently has issues related to subs. Specifically, the opcodes for the sub aren't frozen with the sub. The reason for this is that, when a sub is a constant in a PBC, the opcodes are stored elsewhere and the sub should be an index into the code segment. Also, PBCs as they currently exist are more or less equivalent to frozen Eval PMCs (in function, not format). The bottom line is we have 2 formats that are inter-dependant and have overlapping functionality. = Proposed Solution = Have freeze/thaw operate on a slight variant of PBC. That is, freeze returns a string containing the contents of a PBC file, and thaw would operate on such strings. = Required Modifications to PBC = Minimal. A new segment would need to be added for non-constant objects. For backwards compatibility, we could make the absence of this segment default to creating an Eval PMC. = Required Modifications to freeze/thaw = The IMAGE_IO object (or whatever we replace it with) would need to gain the concept of bytecode management. Sub PMCs would be responsible for adding their bytecode to the image on freeze and obtaining their bytecode on thaw. Eval PMCs would no longer manage the bytecode for all contained subs for freeze/thaw as these are now responsible for handling that themselves. = Benefits = * Elimination of duplicated functionality. * Sub PMCs frozen/thawed sanely. * PBC becomes more flexible from PIR/HLL perspective: * compilation: just freeze an Eval PMC. * examination: thaw to Eval PMC and poke it * load_bytecode is something like: {{{ .sub 'load_bytecode' .param string filename $S0 = slurp_file(filename) $P0 = thaw $S0 $P0() .end }}}",plobsing 4, Release,1416,Unreasonably painful to add a method to all *Array PMCs,core,2.0.0,,new,2010-01-25T19:22:30Z,2010-02-02T07:08:38Z,"Adding a method that works for all *Array PMCs (in either PIR or NQP) should be really easy, but it isn't. If all *Array PMCs had a common ancestor (Array, say), you could do this: {{{ module Array { method reverse () { my @reversed; for self { @reversed.unshift($_); } @reversed; } } }}} Unfortunately, there is no such common ancestor. Likewise, they share no common role, so that's not an in either. One could copy and paste the above block for each *Array module, but that's just nuts. Talk about a DRY violation. It's possible one might create one method code object, then iterate over all the known *Array types and use add_method to add that code to them as a method, but this will fail if the list of *Array types changes, which it reasonably might. Plus it's just ugly for what should be a simple task. ",japhb 4, Release,1421,[RFC] zero length FxA behaviour,none,2.0.0,plobsing,new,2010-01-28T17:29:45Z,2010-11-24T17:01:03Z,"FixedBooleanArray, FixedStringArray, FixedIntegerArray, and FixedFloatArray do not allow specifying a length of 0, giving a misleading error of ""Fixed${type}Array: can't resize"". FixedPMCArray ignores being set to zero length, remaining uninitialized. Allowing for zero lengthed arrays allows code that handles ""0 or more elements"" cases to avoid checking against the zero case. For example: {{{ .sub 'fixed_ints_upto' .param int i .local pmc retv retv = new ['FixedIntegerArray'] retv = i $I0 = 0 loop: if $I0 >= i goto end_loop: retv[$I0] = $I0 inc $I0 goto loop end_loop: .return (retv) .end }}} This will currently fail. To avoid failures, we would have to check for a zero valued argument and handle that case separately. Zero is a valid length for an array, so I propose that we allow FxAs to be set to zero length (and not be subsequently resizable). Alternatively, the behaviour could be to ignore setting the length to zero (as is done now in FPA). However, this can be seen as violating the set once property of FxA length.",plobsing 4, Release,1433,Add a vtable function to get arithmetic mode,core,2.0.0,,new,2010-02-10T17:20:04Z,2010-06-12T01:08:48Z,"After talking with Allison yesterday, I would like to suggest that we add a new VTABLE_get_numeric_mode(). This VTABLE would return a flag value to determine whether the PMC should be treated as an INTVAL or a FLOATVAL in an arithmetic calculation. Currently we have a large series of mathematics vtables that are called from the math.ops. These mathematics vtables allow the PMC to determine how it participates in the operation. The downside to this setup is that we need a large number of vtables for all supported operations. For every operation where we do not have a corresponding vtable, we must decide whether to treat the PMC as an INTVAL or a FLOATVAL, a decision which is going to create problems for some types. Having a VTABLE interface that allows the PMC type to describe whether it is int-like or float-like will allow us to encapsulate more operations better, and make better decisions in more situations. Also, it will allow us to slim down the VTABLE structure to remove a few operations which are rarely used except in numerical types and only to make these decisions for us. Alternatively to a new VTABLE function, we could have some sort of flag mechanism in the VTABLE structure and check it with a macro. I suggest we need at least three outcomes: A PMC is either int-like, float-like, or non-numeric. Attempting to perform a non-overridden math op on a non-numeric PMC could throw a meaningful error instead of just falling back to the implementation in default.pmc. Opinions and comments much appreciated ",whiteknight 4, Release,1434,Slim down selection of mathematics vtables,core,2.0.0,,new,2010-02-10T17:28:38Z,2010-11-25T18:27:30Z,"We have far too many mathematics vtables for too many combinations of input arguments. I would like to make the following suggestions: - Convert all ""3-argument"" VTABLEs to ""2-argument"" ones. These are of the form ""PMC * foo(PMC *value, PMC *dest)"". VTABLEs of this form are extremely inconsistent throughout the codebase for the handling of the third ""dest"" argument. In many implementations the third argument is completely unused. I suggest they should all be changed to ""PMC *foo(PMC *value)"", and always return a new PMC that contains the resultant value. - Remove all ""i_*"" vtables. These are less frequently used and tend to be implemented internally in terms of the 3-argument vtables. These changes will signficantly reduce bloat of the VTABLE structure and decrease Parrot's memory footprint and startup times. We'll also be able to have more consistent implementations of the math ops across all core types, and will have a much lower maintenance burden if we need to make changes to these operations.",whiteknight 4, Release,1468,variadic opcodes make assembly/disassembly difficult,core,2.1.0,,new,2010-02-18T19:00:26Z,2010-09-17T01:48:40Z,"opcodes that take a variadic number of arguments are difficult to work with. Some examples of these (maybe the only examples of them) are set_args, get_params, set_returns, and get_results. These ops take lists of values to pass/receive in a call. The first arg to the op is a string or an FIA that contains information about the number of ops that follow. At the very least, these ops should be flagged to identify them as being special. This way a PIR-based disassembler can identify them and produce a better listing. Far better idea, in my mind, would be refactoring these ops entirely so that they no longer take variadic lists of arguments. Instead, I suggest we could have IMCC build CallContext PMCs (or a new kind of proto-CallSignature PMC instead, depending on preprocessing requirements) at compile time and store them in the constants table. So set_args_p would change from taking an FIA with a series of flags and then a variadic argument list to taking a single ""CallArguments"" PMC which would contain all the same information, but in a form that was much easier to work with. Since information about the arguments to a function call are already stored as constants in the bytecode stream directly, we can easily convert this to a PMC constant with no loss of dynamicism. If anything we gain more dynamicism because we gain the ability to construct argument lists at runtime without having to explicitly use :flat. These kinds of refactors would dovetail nicely with other PCC refactors currently planned. Ideas? ",whiteknight 4, Release,1470,Create a get_numeric_pmc VTABLE,core,2.1.0,,new,2010-02-19T16:23:59Z,2011-06-11T14:19:18Z,"the get_integer and get_number VTABLEs are limited because they return a particular numeric type without any indication for the preference of the PMC. For instance, some PMCs may prefer to be treated as an integer value or as a floating point value for mathematical calculations. Also, it is nonsensical to ask certain PMCs for a floating-point value or to ask other types for an integral value. If you look at a code example from an HLL like this: {{{ $c = $a + $b }}} it is difficult to know how to treat the operation and whether to store an int-like or float-like value in $c. This is especially true when considering types that aren't typically used in equations, such as array types. When treated as a number, should ResizablePMCArray act like a float or an int? For example NQP treats all mathematic operations as float-point and requests values from PMCs accordingly. I would like to suggest the creation of a get_numeric_pmc VTABLE that would return a numeric PMC type that can be used as a stand-in for a non-numeric type in calculations and preserve information about whether the type should be treated as a float or an int. An RPA could return an Integer PMC as we expect, but other types that prefer it could return Float, BigInt, BigNum, or even Complex types as required. In this way we could get proper information about the use of a PMC in a mathematical context without having to shoehorn unnecessary and nonsensical get_number and get_integer vtables into all our types, an without requiring Parrot to make decisions about type conversion or type promotion. The HLLs should handle those kinds of decisions without Parrot making defaults. In additon to the new VTABLE we would likely need a new opcode to expose it.",whiteknight 4, Release,1641,iseq does not support the same type of operands as the math operators,imcc,2.3.0,,new,2010-05-15T23:10:34Z,2010-05-15T23:14:21Z,"# Within a method ... This doesn't work. {{{ $I0 = 1 $P0 = getattribute self, 'someIntField' $I1 = iseq $I0, $P0 }}} # Error message: # error:imcc:The opcode 'iseq_i_i_p' (iseq<3>) was not found. Check the type and number of the arguments There is already support for math operands with mixed types, so allowing iseq to have the same behavior is good for consistency: {{{ # Test by bacek ~/src/parrot (ops_pct_local)$ cat t.pir .sub ""main"" $N0 = 40.0 $I0 = 2 $N1 = $N0 + $I0 say $N1 .end ~/src/parrot (ops_pct_local)$ ./parrot t.pir 42 }}}",shockwave 4, Release,1644,[RFC] Text format serializer for PASM/PIR constants,imcc,2.3.0,,new,2010-05-17T06:18:54Z,2011-08-27T16:57:03Z,"This would allow the freezing and thawing of arbitrary constants that can be held in PBC to and from PIR/PASM. Attached is a proof of concept PMC to acheive the serialization/deserialization. Currently it only serializes, but it is based on the ImageIO API for object serialization/deserialization and mostly reuses existing tokens from PIR/PASM, so the deserializatoin shouldn't be terribly difficult. New syntax would also have to be added to demarkate the beginings and ends of constant sections as well as to use constants in code sections. Perhaps '.begin_data(123)', '.end_data', and '$C123'. I haven't put much work into what the punctuation should be and I'm not quite happy with it yet. I'd appreciate advice in this area especially. ",plobsing 4, Release,1645,Request for another overload to 'not' opcode.,none,2.3.0,,new,2010-05-17T15:39:48Z,2011-11-20T10:05:38Z,"The docs page: http://docs.parrot.org/parrot/latest/html/src/ops/cmp.ops.html ...mentions 2 overloads for opcode 'not': {{{ not(out INT, in INT) not(out PMC, invar PMC) }}} It would be sweet to have another overload for opcode 'not'. {{{ not(out INT, invar PMC) }}} This would avoid the need for boxing of the operands in many cases.",shockwave 4, Release,1662,Should NameSpace entries be available through a hash-like interface?,core,2.4.0,,new,2010-05-27T23:57:46Z,2011-07-06T02:25:55Z,"Several notes I've run across make references to the fact that NameSpace PMCs should be searchable using a hash-like interface to find entries in the namespace. There aren't a lot of details in these spattered notes, so I don't know whether it suggests we should be able to lookup nested namespaces using such an interface, or NameSpace global entries, or both. Here's an example of a note from src/global.c: {{{ NOTE: At present the use of the {get, set}_global functions is mandatory due to the wacky namespace typing of the default Parrot namespace. Eventually it will be safe to just use the standard hash interface (if desired). }}} Let's figure out exactly what these notes mean, what we want the NameSpace interface to be, and make everything right.",whiteknight 4, Release,1747,Switch shift and pop for reverse iterators,core,2.6.0,,new,2010-08-19T22:01:22Z,2010-08-19T22:01:22Z,"Currently, you're supposed to use ""shift"" with normal iterators and ""pop"" with reverse iterators. I think that doesn't make sense. If I have a function that takes an iterator as argument, how does it know whether to use shift or pop? I think that shift and pop should be switched for reverse iterators.",nwellnhof 4, Release,1885,Parrot_load_bytecode should only load bytecode,core,master,cotto,new,2010-12-09T15:09:03Z,2011-08-27T18:02:49Z,"The function src/packfile.c:Parrot_load_bytecode() is too magical. It not only loads bytecode, but it also does some rudimentary extension string matching to also allow it to load .pir and .pasm file. This is extremely magical and is not made clear through the function's name. This function is exposed primarily through the load_bytecode PIR op, which has similar magical behavior. I suggest that we eliminate the magical behavior of this function and the opcode that exposes it: load_bytecode and Parrot_load_bytecode should *only* load bytecode files under any extension. If the user wants to compile a PIR source file they should use the PIR compreg.",whiteknight 4, Release,1921,RFC: decorate all functions in src/platform.c with PARROT_EXPORT,core,2.10.0,cotto,new,2011-01-01T00:12:50Z,2011-08-29T23:46:40Z,"I propose that we add PARROT_EXPORT to all functions in src/platform.c (i.e. all functions in all files used to generate src/platform.c). This is necessary so that users of libparrot, in this case dynpmcs, can access platform-specific functions. The problem that brought this up was that the OS pmc couldn't access Parrot_get_user_id, but I can imagine this cropping up in other places too. I've created a gci task for this and rfw plans to work on it, but I want to make sure I'm not missing anything before I merge into master.",cotto 4, Release,2133,src/extend.c Review,embed/extend,master,whiteknight,new,2011-06-13T00:57:37Z,2011-06-13T23:29:20Z,"The functions in extend.c and extend_vtable.c use the PARROT_CALLIN_START and PARROT_CALLIN_END macros to ensure the stacktop value is set for proper GC operation. This is unnecessary for two reasons: 1) We have an embedding API, and a clear distinction between embedding and extending situations. In an extending situation, the stacktop should always be set. 2) The functions in extend.c and extend_vtable.c represent only a small subset of what we currently consider the ""extending API"". Many extension libraries use other subsystem API functions directly, and some extension libraries never use any of the functions defined in extend.c or extend_vtable.c, which means those libraries would never see this protection (and they aren't any worse off for it). If those two macros go away (And I suggest they should), there are a few functions in extend.c which can go away because they are nothing but wrappers around other functions: - Parrot_PMC_new (Parrot_pmc_new) - Parrot_free_cstring (Parrot_str_free_cstring) - Parrot_register_pmc and Parrot_unregister_pmc - Parrot_register_string and Parrot_unregister_string Also, there are a few other functions which need to be re-considered: - Parrot_get_*reg and Parrot_set_*reg (These functions should take a PMC * for the context, because the *_REG macros are going to read from the current context, which in an extending or NCI context is likely to be worthless. Also, these functions don't do any bounds-checking) - All the Parrot_printf-related functions. We have similar functions in src/utils.c and elsewhere which integrate properly with the IO and String subsystems - Parrot_new_string (Should probably be moved to src/string/api.c, because it's just a wrapper around Parrot_str_new_init with some logic to lookup encodings by name) Also, it would be very good if we had an ""official"" definition for what our extending API is. Is it, as is the de facto definition, the sum of the individual subsystem APIs, or is it something distinct?",whiteknight 4, Release,2163,Reconsider IGLOBALS_PBC_LIBS,core,master,,new,2011-07-23T12:52:10Z,2011-07-26T01:15:33Z,"The global IGLOBALS_PBC_LIBS stores a mapping of file name to full path name for entries loaded with load_bytecode_s (Deprecated in #2146). Since load_bytecode_s can be used to load a .pbc, .pasm, or .pir file, and automatically compiles files if necessary, the mapping key is the filename without the extension. With the new load_bytecode_p_s op, we can start to redesign this data item. The new op returns a PackfileView PMC when loaded and currently does not cache values. If you do ""$P0 = load_bytecode 'foo.pbc'"" twice, it will attempt to load the same file twice into two PMCs. I don't know if this is considered a bug, or something we want to keep. After all, it's entirely possible that a .pbc file could change during program execution, and re-loading it will return a packfile with different contents. If we want to have a cache still, I suggest we repurpose IGLOBALS_PBC_LIBS to map full path name to PackfileView result. The user can, of course, get access to this hash and delete keys from it if she wants to reload it. Then, we can update the new load_bytecode_p_s op to use the repurposed cache. Similarly, we can deprecate IGLOBALS_PBC_LIBS and replace it with a new cache so that both load_bytecode ops have a cache to use during the deprecation period. If we do not want Parrot to contain an explicit hash, we can let IGLOBALS_PBC_LIBS be deprecated and removed when load_bytecode_s is. User code can keep track of the libraries they want to load themselves.",whiteknight 4, Release,2167,Storable format breaks pmc2c when Perl is upgraded,pmc2c,3.6.0,,new,2011-07-30T08:46:54Z,2011-08-08T23:22:25Z,"Downstream in Debian, the upgrade from Perl 5.10 to 5.12 broke Rakudo compiles, because the installed PMC .dump files were written using the 5.10 version of Storable, and could not be read using the 5.12 version of Storable. The upstream bugs (closed) related to this failure are: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634105 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634970 This is solved in the short-term, but in the longer-term, Storable is not a good format for installed, persistent metadata. (It was never intended to be installed, only to be a temporary build-process cache.) We need to re-examine what metadata pmc2c actually needs for building PMCs that inherit from core Parrot PMCs. I suspect that it's actually much smaller than the current .dump files, and that installing some simple JSON metadata files for the core PMCs would actually be sufficient. The work on M0 will eventually make this irrelevant, but that work would likely also benefit from some thought about abstracting the metadata needed to inherit from a PMC. ",allison 5, Release,61,Investigate using an external hash library,library,,cotto,new,2008-12-17T20:42:04Z,2011-02-02T19:27:58Z,"We spend a lot of cycles on our hand-rolled hashing, both in terms of developer effort and CPU. It would be nice if we could use an off the shelf hash package. Any package under consideration would have to have a compatible license, and work on our minimal core platforms.",coke 5, Release,1448,Modify `throw` opcode to pass through pre-configured resume continuation,core,master,whiteknight,assigned,2010-02-16T01:10:15Z,2011-10-24T12:49:43Z,"Presently, the throw opcode creates and sets a resume continuation on the exception being thrown. Since 'resume' is an attribute of the Exception, throw should check first for a preconfigured continuation, and if one exists should preserve it. (Of course, if unset it should continue to do what it does.)",Austin_Hastings 5, Release,2125,rename parrot.h to internals.h or private.h or equivalent,core,master,,new,2011-05-26T22:57:41Z,2011-05-26T23:38:28Z,"Several lines at the beginning of parrot.h read: {{{ /* Only parrot core files should include this file. Extensions should include . Programs embedding parrot should include . */ }}} A far more effective approach would be to rename ""parrot.h"" to ""internals.h"" or ""private.h"" or something that makes it much more obvious that the contents are meant for internal use only. People looking to Parrot source code for examples of how to write PMCs, dynpmcs or dynops are unlikely to read the contents of parrot.h and see the warning. Pm",pmichaud 5, Release,2155,Additional README Files in Top-Level Directories,docs,master,soh_cah_toa,new,2011-07-17T23:02:20Z,2011-08-02T02:43:18Z,"In a recent [http://lists.parrot.org/pipermail/parrot-dev/2011-July/006010.html email] to parrot-dev, kid51 brought up the question of whether each top-level directory could benefit from a small README file describing their purpose. A few of them already do but I think making this a consistent practice is a great idea. The purpose of these directories is not always self-evident and personally, I still don't know what they all are for. I don't see any immediate disadvantages to this other than a small increase in size. Even so, if the cost of further clarifying our directory structure is just a couple extra kilobytes, I say ""so what."" The format of each README should be consistent and in plain text. Perhaps something like: {{{ Directory: [name] Summary: [short summary] Description ----------- [more verbose description] Subdirectories -------------- [name - short summary] [name - short summary] ... }}} ",soh_cah_toa 7, Release,2114,getprop op is strange,core,master,,new,2011-05-18T15:35:08Z,2011-05-19T15:13:29Z,"The getprop op is strange because it has a signature getprop_p_s_p. By analogy, the getattr opcode has signature getattr_p_p_s. setprop_p_s_p and setattr_p_s_p are similar and are not a problem. getprop_p_s_p should be changed to getprop_p_p_s for symmetry with other ops. Also, we should take some time to reconsider the whole properties mechanism, since I don't think it is used often. It *is* used, but not often and I'm not sure that it's the best mechanism for doing what we want to do with it.",whiteknight 4,2.11 Release,1864,[RFC] Change coding standard to avoid 2 space outdent.,coding_standards,2.10.0,jkeenan,new,2010-11-23T10:53:52Z,2011-08-27T17:38:53Z,"Hello. Current coding standard requires 2 space indent on switch/case indent. I would like to propose to change it to 4 space and close #1547 as ""wontfix"". Basically I speak about this patch: {{{ diff --git a/docs/pdds/pdd07_codingstd.pod b/docs/pdds/pdd07_codingstd.pod index 8741a1b..52dc866 100644 --- a/docs/pdds/pdd07_codingstd.pod +++ b/docs/pdds/pdd07_codingstd.pod @@ -110,11 +110,6 @@ the level of indenting to increase. =item * -Labels (including case labels) must be outdented two columns relative to the -code they label. - -=item * - Closing braces for control structures must line up vertically with the start of the control structures; e.g. C<}> that closes an C must line up with the C. }}} Or at least change ""including"" to ""excluding"". -- Bacek",bacek 4,2.11 Release,1867,RFC: optional fakecutable preamble,none,2.10.0,,new,2010-11-23T21:26:04Z,2011-01-11T09:44:26Z,"Executables created by pbc_to_exe, better known as ""fakecutables"", don't have full access to parrot VM settings. We currently work around some of these problems with magic environment variables and flags on pbc_to_exe. These solutions are crufty and inflexible. I propose the option to add a second pbc which will be loaded *before* the main pbc and run. The results of this will be used as the settings with which to run the main pbc. The intent of this secondary, preamble, pbc is to parse commandline arguments, environment variables, and config files to obtain parrot VM settings in a manner appropriate for the HLL.",plobsing 4,2.6 Release,903,[RFC] Deprecate Keys at all.,core,trunk,,new,2009-08-05T21:20:58Z,2011-02-24T08:30:59Z,"Hello. (Background: I've spent few months trying to make Keys and Iterators more sane) There is excerpt from IRC log: {{{ chromatic: I've got excellent (fsvo) idea. Deprecate Keys at all. What would replace them? Create NamespaceKey which will be used for Namespaces. Navigating over ""ordinary"" aggregates will be ""manual"" The idea has merit. indeed. No one uses $P0[foo;bar;baz] It's almost impossible to implement and used correctly. And behaviour is very dependant on HLL It's not easy to manage in IMCC either. e.g. autovivify vs throwing exception. So, NamespaceKey will has-a RSA Simple, clean, comprehensible. Remove a lot of code in Hash and Array to support Keys. Simplify IMCC and future of PIRC (which doesn't support complex keys) It's worth considering. }}} Actually NamespaceKey can be is-a RSA. Then creating it in pir will be something like {{{ $P0 = split ';', 'foo;bar;baz' $P1 = new [NamespaceKey] $P1 = $P0 }}} -- Bacek",bacek