Note that adding your thoughts here does not necessarily imply that they'll actually be considered or implemented. This is simply a place for suggestions and discussions. Naturally, the more well thought out your ideas are, the more likely they'll be taken into consideration. __Pike Eclipse Integration__ see [PikeDevel/Eclipse]. __Pike Debugger__ Every language needs a debugger, right? ~~Current Status:~~ See [PikeDevel/PikeDebugger]. Formerly: an embryo of a debugger currently exists as "unbug" which uses gdb as its core debugging engine. it's minimally functional, though native code generation currently disables breakpoints and stepping. Initial code to map local variables to variable names is present, but is weak at best. ~~Who to talk to:~~ any of the core pike developers could point you in the right direction. A mail to pike-devel would be the best place to start. __Better documentation__ We need better documentation in order to lure (pun intended) new pike fans. ~~Current Status:~~ a tutorial book is available from http://book.gotpike.org. Core pike internals documentation has been started using doxygen. ~~Who's working on it:~~ Contact Bill Welliver or Martin Baehr for the tutorial, and any of the core pike developers for internals documentation. We're using doxygen to document things, so you can grab a copy of pike from CVS and start documenting! __Better external module support__ We'd like to be able to distribute core modules separately from pike, such that users can install a stripped version of Pike and install only the modules they need. It would also be nice for users to be able to update these core modules independently of the Pike release they're using. ~~Current Status:~~ some minor changes should be made to the internal module build environment to synchronize it with the way external modules are currently built, according to Grubba. Once that's done, modules should be modified to include version data so that monger can support updating them. __GTK2 support__ ~~Current Status:~~ A new GTK2 module based around the original GTK module (but without the GTK1 support) is available in Pike 7.8 releases. ~~Who's working on it:~~ Lance Dillon is leading the charge here; his code is present in the 7.8/7.9 CVS tree, and QA work is ongoing. __Better XML support__ The current Pike XML parser is rather slow and is missing support for a fair number of now-common XML related technologies, such as XPath, XSLT and the like. The parser is also non-validating, which limits its usefulness in certain applications. A glue to one of the well supported XML parsing libraries would be ideal. ~~Current Status:~~ Bill Welliver has implemented a glue based on libxml2. It's more or less complete (depending on what functionality you're interested in), but has a large number of useful features: XSLT support, XPath support, RelaxNG validation, SAX and XMLReader style interfaces. Assistance in testing and identifying opportunities for improvement are welcome. __XML Schema support__ It would be nice to have some tools that made it easier to work with XML Schema. Things such as a code generator that converted an XSD to Pike classes, and vice versa. libxml2 support for XML Schema is currently limited to validation, so we'd accept work on libxml2 such that the XML2 binding could be enhanced. __SOAP Support__ Pontus Östlund has done a basic SOAP support module; you can find his code (along with a number of other cool modules) at GitHub: https://github.com/poppa/Pike-Modules/tree/master/Standards.pmod __ObjectiveC bridging (Cocoa)__ The ability to interact with ObjectiveC applications would be pretty useful. Primarily, this means Cocoa on Mac OS X, but could also include GNUStep and POC. There are other languages with this sort of functionality already, so it should be doable by someone with some understanding of ObjC. There are both one-directional bridges (such as Lua's) that allow calling and accessing ObjC objects from their respective language, and bi-directional (such as Python's) which allow Objective C applications to access code written in the host language. Obviously, a bi-directional bridge would be ideal, as it would allow Cocoa apps to be written in Pike. ~~Current Status:~~ Bill Welliver is working on a bridge in his spare time. It's bidirectional and supports auto-generated pike wrappers for Objective-C classes, as well as hand coded mixins. Full GUI applications can be written and basic support exists for "plugins", such as Preference Panes. Help is welcomed from those with experience and those without, too. The plan is for this module to be bundled in Pike, but it's got a way to go before that happens. See [PikeDevel/Objective-C Module Design] for some notes about how it's implemented. __Other requests__ - this_function() - see Fins/Tools.Function.this_function() for an implementation.
Powered by PikeWiki2
|gotpike.org | Copyright © 2004 - 2009 | Pike is a trademark of Department of Computer and Information Science, Linköping University|