Re: ICU Outdated - Ideas
At 9:58 AM +0200 8/1/04, Leopold Toetsch wrote: Jerry Gay [EMAIL PROTECTED] wrote: Leopold Toetch wrote: Both ways - or better three stages: Its optional. If its there, we *can* link against it. If you want/need it, and your OS doesn't have it, well, then install it. and if you don't want it you get... what? no unicode support? Exactly. No ICU, no unicode. No. That's just not an option. Parrot must, and *will*, ship with full unicode support. You may choose to not build it, or you may choose to use a system unicode library (right now just ICU) instead of using what we ship with the source, but the option must be there, and therefore ICU will continue to stay in CVS as part of parrot. Period. The alternative here is the same alternative as with GMP and big numbers--we can yank ICU *if* someone writes an alternate Unicode implementation for us. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: ICU Outdated - Ideas
--- Dan Sugalski [EMAIL PROTECTED] wrote: ... and therefore ICU will continue to stay in CVS as part of parrot. Period. The alternative here is the same alternative as with GMP and big numbers--we can yank ICU *if* someone writes an alternate Unicode implementation for us. -- Dan The following comments aren't directed at you Dan, just my personal opinion on ICU. ICU is giving Parrot a black eye. The ICU we have in CVS right now is really old and broken. We are shipping a bare bones version of ICU that doesn't build very easily anywhere. I don't want to sound like I am complaining without offering to help out with the work. I just didn't want to take the initiative without direction and have it be an excersise in futility - that's why I made multiple suggestions. Ok - so which way do we go? A. Leave it as is B. Upgrade to a bare bones 3.0 C. Upgrade to a full version of 3.0 D. Improve the config/gen/icu.pl with any of the previous options E. Something else entirely? Joshua Gatcomb a.k.a. Gat (240) 568-5675 __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
The Roadmap
I got asked a lot at OSCON, and this has been something of a topic on and off on the list. I've committed a DESIGN_TODO file with brief details of what I think still needs working on, which I'll be adding to as things make themselves obvious (I've got a bigger list on paper this morning) so there's some notion of what needs thinking about. Here, though, is a short term roadmap. These are the things I want to deal with in the near future--probably through the end of august. If it's not on here, look in DESIGN_TODO and see if it's there. (If it's not in either place, then we need to add it to some list somewhere) 1) Finish the pie-thon post-mortem (this may add things to the list) 2) Get the return continuation, calling sub/method, and invoked object moved to the interpreter structure 3) Get serializable continuations working 4) Figure out what Leo's talking about with his proposal and see what works out 5) Finish piethon bytecode converters. (Yes, this isn't as good an option as writing a python compiler from source. If someone wants to tackle that I'm fine with it) 6) Get the strings design properly implemented 7) Get the namespace stuff worked out and implemented Longer term: *) Finalize the Event/IO PDD *) Finalize the thread PDD *) Finalize the notification system *) Finalize PMC wrapping *) Finalize Async IO internals system *) Get the loadable pmc/opcode stuff working and documented *) Finalize the security PDD -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: ICU Outdated - Ideas
At 6:20 AM -0700 8/3/04, Joshua Gatcomb wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: ... and therefore ICU will continue to stay in CVS as part of parrot. Period. The alternative here is the same alternative as with GMP and big numbers--we can yank ICU *if* someone writes an alternate Unicode implementation for us. -- Dan The following comments aren't directed at you Dan, just my personal opinion on ICU. ICU is giving Parrot a black eye. The ICU we have in CVS right now is really old and broken. We are shipping a bare bones version of ICU that doesn't build very easily anywhere. Which is definitely a major pain. What I'd like to do is this: 1) Get Configure smart enough to check for, and use, the system ICU if it's in, instead of what we ship. 2) Get our ICU working reasonably well. If this means ripping it out and replacing it with 3.0, we can do that If someone's tempted to do 3) Write our own Unicode system, I'm OK with that too. The string internals doc needs writing, and I can get that done. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: ICU Outdated - Ideas
Dan Sugalski sent the following bits through the ether: If someone's tempted to do 3) Write our own Unicode system, I'm OK with that too. The string internals doc needs writing, and I can get that done. IIRC the mono people wrote their own, but with the ICU data files. Apart from license issues, this might be an interesting thing to look at. Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Better to understand a little than to misunderstand a lot
RE: ICU Outdated - Ideas
Joshua Gatcomb wrote: Dan Sugalski dan at sidhe dot org wrote: ... and therefore ICU will continue to stay in CVS as part of parrot. Period. The alternative here is the same alternative as with GMP and big numbers--we can yank ICU *if* someone writes an alternate Unicode implementation for us. The following comments aren't directed at you Dan, just my personal opinion on ICU. ICU is giving Parrot a black eye. The ICU we have in CVS right now is really old and broken. We are shipping a bare bones version of ICU that doesn't build very easily anywhere. This sounds familiar. There was a Wine project interview with Wine's internationalization guy, Shachar Shemesh a couple weeks back: http://www.winehq.com/?interview=16 Shachar: ICU has all the BiDi support we will ever need. Well, almost - it will probably be too hard to make it more MS BiDi compatible, but that is not a major issue. What is a major issue with ICU is that it is an entire Unicode implementation. This means it has lots and lots of stuff that Wine does itself. For example - GDI without BiDi support is ~2MB. With BiDi support from ICU statically linked, after ICU has been trimmed of all the easy-to-remove stuff, it grows to ~4MB. Without this trimming, it grows an additional 7MB to 11MB! Don't forget that GDI neither uses nor needs most of that code. I guess things would not be so bad if you could just say I'll just dynamically link it. For all practical purposes, you can't. As a design decision, ICU has the library version mangled into each function name. This means that you have to have the same version installed on the machine as the one you compiled with, or it won't be usable. As a byproduct of this, nobody uses ICU dynamically. Both Mozilla and OpenOffice use ICU for their reordering, and both of them statically link it. As a byproduct of that, almost no distro carries ICU, or carry a very old version of it. In short, I would like to ditch ICU as soon as possible. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
PMC basics
I know this was discussed earlier, but I think its still an issue. First python's usage of values aka builtin objects: 1) almost all opcodes create a new object as result (the value) 2) LOAD_NAME | STORE_NAME (or _GLOBAL or _FAST) opcodes deal with variables, the value is fetched or stored from locals or globals. 3) objects are differently sized, an 'int' is just 3 words long Now our POV with PMCs: 1) we need to create the LHS of almost all operations first 1a) but we don't know which PMC type is needed, so we create an Undef and morph() that to the desired PMC type 2) lexical or global ops or both for Python's weird name handling 3) as we guarantee that PMCs don't resize, the minimum PMC size is 5 words This really doesn't fit together. We can't take advantage of the reference semantics of our opcodes. I can't emit add a, $P0, $P1 to create the result directly in the variable 'a', because I don't know if its aliased before by 'b = a'. We have to create a new temp for the LHS and store that then. Second is the dogma that PMCs don't resize or don't move. Python has differently sized objects. There must be a way to implement that in Parrot too. Further: 1/ 1a) also means that we never can emulate this: $ python Python 2.3.4 (#2, Jun 19 2004, 18:15:30) [GCC 3.3.4 (Debian)] on linux2 Type help, copyright, credits or license for more information. a = 2 + 4 b = 3 + 3 a is b True - yes, these objects have the same address id(a) == id(b) This might not be too important, Python will break it in some cases with the unification of 'int' and 'long'. But there may be other cases, were objects have to be created by the opcode (or vtable) and not beforehand. leo
Re: ICU Outdated - Ideas
On Tue, Aug 03, 2004 at 03:09:02PM +0100, Leon Brocard wrote: Dan Sugalski sent the following bits through the ether: If someone's tempted to do 3) Write our own Unicode system, I'm OK with that too. The string internals doc needs writing, and I can get that done. IIRC the mono people wrote their own, but with the ICU data files. Apart from license issues, this might be an interesting thing to look at. It would remove the dependency on C++ But is the amount of effort too much like hard work compared with integrating 3.0? Nicholas Clark
Starting to make things final
In what's seems a rather bizarre twist, Parrot's getting production ready. Yes, I find this really strange, and no, I'm not even talking about my work project, though I probably should. Python and PHP are both near-beta ready, and Span looks... well, it looks damn nice. As such, I think we're in a state where the things that have been in and implemented should be documented and fixed, and the things that are in flux should un-flux and get fixed. I'm tired of most of languages/ being broken as well -- I'd like to get forth, BASIC, Jako, Cola, and the rest all working again, and like to not break m4. So, here's what we're going to do. First, I'm digging into Leo's proposal for changing sub calls. It has user-visible issues in that when we're done hashing it out, it'll mean no need to do save/restores. Next we're going to put the return continuation, sub PMC, and object PMC into the interpreter structure. They can stay in the registers they're in now, I expect. That'd be convenient, and we're not really short of registers. Then we kick the python bytecode compiler around until it works. This will, I expect, involve finalizing exceptions, so we will. When we're done with that we're going to release 0.2.0. After that we're going to revisit, and then lock down, the embedding and extending APIs. When we're done with those, we're *done*. We'll put together source tests, which'll remain canonical unless the tests themselves have bugs. Then we release 0.2.1. After that I think we address the string internal issues, and dynamic string loading. We'll also tackle, I think, serializable continuations. Then we release 0.3.0. From there I don't want to speculate, but events/IO and threads are next on the hit list. Questions? This'd be a good time to suggest changes to the timeline... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Everything Parrot
I've had this list lying around for too long, but never seem to find time to make it all shiny and complete. I want to have another go at the html documentation. But before I start I'd prefer to have a good list of everything Parrot. That way I can build a proper subject view of the project. It would be nice if people just email me what I've missed. I'm hoping if folk just state what's obvious to them I'll get good coverage. I've put it on the wiki as well, so if you prefer to edit that, fine by me. http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/EverythingParrot =head1 Subsystems and Resources =head2 Memory Allocation Resource pools =head2 Registers and Stacks Register sets Frame stacks Int stack User stack Pad stack Control stack Regex stack =head2 PMC Internal structure (PObj, Buffer, PMC_EXT) Vtables PMC hierarchy and (multiple) inheritance Abstract PMCs Dynamic PMCs Serialization (Freeze/Thaw and Dumper library) Constant PMCs PMC template creation Loading and initialization sequence Descriptions of individual PMC types (probably discussed under separate subjects) How to create a specific type of PMC using Parrot Extensions interface Assignment in PASM/PIR C macros Null PMC Layering Morphing Properties =head2 Interpreter [...] =head2 Exec [...] =head2 Debugging [...] =head2 Big Number Arithmetic Decimal Arithmetic =head2 Namespaces Separators =head2 Dead Object Detection (DOD) and Garbage Collection (GC) Mark and sweep (?) Timely destruction (?) ARENA_DOD_FLAGS =head2 Copy on write (COW) [...] =head2 Parrot Operations (Ops) Call and return conventions Variable length parameter lists Opcode numbering =head2 Subroutines Closures Coroutines Continuations =head2 Multi-Method Dispatch Rules for method resolution =head2 Objects Classes and metaclasses =head2 Keys Keyed access =head2 Threads Thread safety =head2 IMCC and PIR [...] =head2 PASM [...] =head2 Events [...] =head2 Parrot Strings Unicode ICU =head2 Native Call Interface (NCI) [...] =head2 Just-in-time compilation (JIT) [...] =head2 Exceptions [...] =head2 Miniparrot [...] =head2 Extensions Interface [...] =head2 Embedding Interface [...] =head2 Bytecode Packfile format Metadata =head2 IO Asynchronous IO stat =head2 Lexical Scope and Scratchpads [...] =head2 Regular Expressions =head2 Libraries SDL ncurses Postgres PCRE Dynamic opcode libraries Includes =head2 Configuration Configure.pl Initialization User Dialogues System Tests File Creation =head2 Building and Installing make =head2 Editor plugins Emacs VIM Kate =head1 Subjects orthogonal to subsystems =head2 Platform Specifics PLATFORMS cygwin mingw =head2 Tests Writing tests Parrot::Test make arguments =head2 Benchmarks and Optimization [...] =head2 Examples [...] =head2 C source code Coding standards typedefs Macros =head2 Perl source code CPAN Modules =head2 Documentation Uppercase named text files POD General Documentation Specific Documentation Development Documentation PMC Documentation Perl Design Documents (PDD) Parrot::Docs modules =head1 Things outside the distribution =head2 CVS Parrot source code repository access CVS Monitor =head2 Related projects Ponie Pirate mod_parrot YAL OpenComal Russian documentation Perl 6 regular expressions Parrot on Windows (POW) =head2 Resources Perl6 internals mailing list and its weekly summary Tinderboxes Perl6 Essentials (O'Reilly) =head1 Languages which target Parrot =head2 How to target Parrot [...] =head2 Languages in the Parrot distribution Perl6 Jako BASIC Regex TCL Cola Scheme URM Ruby miniperl Befunge BF Ook! PLOT Python Forth PASM
Re: ICU Outdated - Ideas
Although I sent this ideas to this list, with another subject, here they go again to enter in the correct thread. I think that to have ICU included both in CVS and tarballs created for parrot is not the best way. I know Dan (and maybe some others) do not want to depend on too much libraries. The main problem should not be on depend on ICU, but ICU not being usual on most systems. So, we are scripting people (or this wouldn't be a perl mailing list). Then, we should be able to make Configure to test if ICU is in the system. If not, use the Internet connection to get it, untar, configure and compile. I think that nowadays it is very difficult to find someone trying to compile parrot without a network connection. OK, this is my feeling to the problem. Cheers, Alb Garrett Goebel wrote: Joshua Gatcomb wrote: Dan Sugalski dan at sidhe dot org wrote: ... and therefore ICU will continue to stay in CVS as part of parrot. Period. The alternative here is the same alternative as with GMP and big numbers--we can yank ICU *if* someone writes an alternate Unicode implementation for us. The following comments aren't directed at you Dan, just my personal opinion on ICU. ICU is giving Parrot a black eye. The ICU we have in CVS right now is really old and broken. We are shipping a bare bones version of ICU that doesn't build very easily anywhere. This sounds familiar. There was a Wine project interview with Wine's internationalization guy, Shachar Shemesh a couple weeks back: http://www.winehq.com/?interview=16 Shachar: ICU has all the BiDi support we will ever need. Well, almost - it will probably be too hard to make it more MS BiDi compatible, but that is not a major issue. What is a major issue with ICU is that it is an entire Unicode implementation. This means it has lots and lots of stuff that Wine does itself. For example - GDI without BiDi support is ~2MB. With BiDi support from ICU statically linked, after ICU has been trimmed of all the easy-to-remove stuff, it grows to ~4MB. Without this trimming, it grows an additional 7MB to 11MB! Don't forget that GDI neither uses nor needs most of that code. I guess things would not be so bad if you could just say I'll just dynamically link it. For all practical purposes, you can't. As a design decision, ICU has the library version mangled into each function name. This means that you have to have the same version installed on the machine as the one you compiled with, or it won't be usable. As a byproduct of this, nobody uses ICU dynamically. Both Mozilla and OpenOffice use ICU for their reordering, and both of them statically link it. As a byproduct of that, almost no distro carries ICU, or carry a very old version of it. In short, I would like to ditch ICU as soon as possible. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com -- Alberto Simões Much as I hate to say it, the Computer Science view of language design has gotten too inbred in recent years. The Computer Scientists should pay more attention to the Linguists, who have a much better handle on how people prefer to communicate. --Larry Wall
Re: ICU Outdated - Ideas
At 7:22 PM +0100 8/3/04, Alberto Manuel Brandao Simoes wrote: Although I sent this ideas to this list, with another subject, here they go again to enter in the correct thread. I think that to have ICU included both in CVS and tarballs created for parrot is not the best way. I know Dan (and maybe some others) do not want to depend on too much libraries. The main problem should not be on depend on ICU, but ICU not being usual on most systems. So, we are scripting people (or this wouldn't be a perl mailing list). Then, we should be able to make Configure to test if ICU is in the system. If not, use the Internet connection to get it, untar, configure and compile. I think that nowadays it is very difficult to find someone trying to compile parrot without a network connection. While a not unreasonable way to look at it, it's untenable. Counting on a network connection won't cut it, and part of the reason ICU's in CVS now is so that we can make sure things work properly. Obviously they aren't, so we should work this out while we can. The right answer is to make ICU optional, and use the system ICU if it's available, with what we ship as a fallback as a last resort. I'm all for putting in patches for that, as well as making ICU properly optional again. I'd do that now but I'm tight for time for the next few weeks, so that's just not going to happen no matter how much I want it to. If someone's got the time and I spec out the encoding and charset APIs, I'd be thrilled if ICU became optional again. Wouldn't hurt my feelings at all. We need it, because we need Unicode, but it doesn't have to be required. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: ICU Outdated - Ideas
At 18:46 on 08/03/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: If someone's got the time and I spec out the encoding and charset APIs, I'd be thrilled if ICU became optional again. Wouldn't hurt my feelings at all. We need it, because we need Unicode, but it doesn't have to be required. We'll need something that isn't ICU if we're going to do the miniparrot thing. Of course, in the case of miniparrot, it may be possible to forgo unicode altogether, or use a very limited form of it. --Josh
Re: Starting to make things final
Dan -- Thanks for mentioning Jako. It usually gets no respect. :) But, I think Jako is working for some definition of working. But, it is clearly not an idiomatic compiler in that its using old conventions (not surprising, given its history). Did I miss the creation of the compiler-writer list? I need to figure out what needs to be done to convert Jako to a compiler worthy of regular mention, and I suspect the perception problem it has is due to its ageing world-view on how to compile a language down to IMC. Last time I wrote code for it, there were impedence mismatches between IMC and the natural way of thinking about Jako code. Maybe those are gone now, but I could sure use some guidance getting up to speed on The Right Ways as they currently are. Or, should I wait until some of the changes you contemplate in this message so I don't have to change calling convention stuff *again*? Regards, -- Gregor Dan Sugalski wrote: In what's seems a rather bizarre twist, Parrot's getting production ready. Yes, I find this really strange, and no, I'm not even talking about my work project, though I probably should. Python and PHP are both near-beta ready, and Span looks... well, it looks damn nice. As such, I think we're in a state where the things that have been in and implemented should be documented and fixed, and the things that are in flux should un-flux and get fixed. I'm tired of most of languages/ being broken as well -- I'd like to get forth, BASIC, Jako, Cola, and the rest all working again, and like to not break m4. So, here's what we're going to do. First, I'm digging into Leo's proposal for changing sub calls. It has user-visible issues in that when we're done hashing it out, it'll mean no need to do save/restores. Next we're going to put the return continuation, sub PMC, and object PMC into the interpreter structure. They can stay in the registers they're in now, I expect. That'd be convenient, and we're not really short of registers. Then we kick the python bytecode compiler around until it works. This will, I expect, involve finalizing exceptions, so we will. When we're done with that we're going to release 0.2.0. After that we're going to revisit, and then lock down, the embedding and extending APIs. When we're done with those, we're *done*. We'll put together source tests, which'll remain canonical unless the tests themselves have bugs. Then we release 0.2.1. After that I think we address the string internal issues, and dynamic string loading. We'll also tackle, I think, serializable continuations. Then we release 0.3.0. From there I don't want to speculate, but events/IO and threads are next on the hit list. Questions? This'd be a good time to suggest changes to the timeline...
(De-Lurk)
Hello, folks. Just wanted to let people know, I've been following parrot and reading the list for a while now, but just recently I finally co'd a copy of parrot and decided it was time that i actually did something with it. The first thing I did was do some work on making it nice in the editor of my choice; I'm the guy who just submitted a couple patches under editors/. But now I'm working on some small stuff, and I think I'm getting it. I'm not sure where I'm going with it yet, but I think that parrot is pretty smooth stuff, and hopefully I can learn enough to actually do something useful with it. We'll find out; I'm on my way into University right now. On a related note, is there a tasks grab-bag list anywhere, some stuff that isn't core work, but It Would Be Nice If, and someone like me could give a shot? Cheers --hobbs
Re: ICU Outdated - Ideas
On Tue, Aug 03, 2004 at 11:32:33PM +0100, Alex Gough wrote: For what it's worth, I checked a parrot out for the first time in ages a couple of days ago (the Shub-tuit gives, as the Shub-tuit takes away...), but got all stuck failing to work out how to get icu not to be a problem, and so get something built to play with. while this isn't constructive to the discussion 1: Argh I can't even build parrot on AIX because we don't have the IBM C++ compiler Game over there. 2: Argh It took the best part of a day, and a custom hacked up perl compile, and some extreme bodging to get parrot to build on Solaris, because the ICU we have defaults to causing the system headers to #error, forced a 64 bit compiler, and something other gotcha that I forget. And given that their default config on AIX puts an IBM compiler specific optimisation flag into the Makefile, I think it will be really uphill making the ICU we have portable, as it appears to be written with defaults per platform (ie OS/arch/compiler combination) rather than the perl approach (conservative, figure things out) But I am biased because I bear the mental scars. Nicholas Clark
Declaring MMD Subs from PASM/PIR
Hi all, I'd like to register some subroutines defined in PASM (or better, PIR) as participating in multiple dispatch. This is very handy when writing Test::Builder::is(), for example, which can compare two strings, integers, numbers, or PMCs, or for calling NCI functions which can take various types and numbers of arguments that all do very similar things. Dan suggested a new op with a scheme similar to: register_mmd S1, S2, P where S1 is the name of the multi sub that users will call, S2 is the name of the sub to dispatch to, and P is an array of types that define S2's signature. The types are the integers as found in datatypes.pasm. Here's some (rough) example PIR: .sub add_integers prototyped .param int x .param int y .local int sum sum = x + y .pcc_begin_return .return sum .pcc_end_return .end .sub add_nums prototyped .param num x .param num y .local num sum sum = x + y .pcc_begin_return .return sum .pcc_end_return .end .sub main .include 'datatypes.pasm' .local pmc signature signature= new Array signature[0] = .DATATYPE_INT signature[1] = .DATATYPE_INT register_mmd 'add_op', 'add_ints', signature signature= new Array signature[0] = .DATATYPE_NUM signature[1] = .DATATYPE_NUM register_mmd 'add_op', 'add_nums', signature .local int intsum .local num numsum intsum = add_op( 2, 3 ) numsum = add_op( 2.5, 2.5 ) print Intsum: print intsum print \n print Numsum: print numsum print \n .end There are other options for declaring the signature. There could be: register_mmd S1, S2, I1, I2, I3, P where I1 is the number of arguments in the I register, I2 is the number of arguments in the N register, I3 is the number of elements in the S register, and P is an array of PMC types. The first signature is pretty simple and the second is a complex signature. There may be something in between with a multi-level array or more complex data structure. There also may be some way of adding 'multi' to the end of a subroutine declaration in PIR, if IMCC is capable of mucking around with symbols based on the types of arguments the subroutine takes -- that'd be really handy, but it's not necessary right now. Comments welcome, -- c
Re: Starting to make things final
At 05:13 PM 8/3/2004 -0700, Gregor N. Purdy wrote: Did I miss the creation of the compiler-writer list? I need to figure No, we are still holding our breath (and turning blue, purple, green, ...) Btw, I'll poke the Cola rewrite I have here and see where it stands. It gathered a bit of dust in the past 6 months. -Melvin
[perl #30946] [PATCH editor/imc.vim.in] Add Macro Highlighting
# New Ticket Created by chromatic # Please include the string: [perl #30946] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=30946 Hi there, Here's a small patch that adds syntax highlighting to macros in .imc and .pir files. If no one hollers in a day or so, I'll check it in. -- c Index: editor/imc.vim.in === RCS file: /cvs/public/parrot/editor/imc.vim.in,v retrieving revision 1.4 diff -u -u -r1.4 imc.vim.in --- editor/imc.vim.in 16 Apr 2004 12:49:11 - 1.4 +++ editor/imc.vim.in 4 Aug 2004 05:10:48 - @@ -29,7 +29,7 @@ syn keyword imcOp call goto if unless global clone addr -syn match imcDirective /\.\(sub\|pcc_sub\|end\|emit\|eom\)/ +syn match imcDirective /\.\(sub\|pcc_sub\|macro\|endm\|end\|emit\|eom\)/ syn match imcDirective /\.\(local\|sym\|const\)/ syn match imcDirective /\.\(namespace\|endnamespace\)/ syn match imcDirective /\.\(param\|result\|arg\|return\)/
