|
Posted
almost 16 years
ago
by
ronny
Since recently there doesn't seem to be much progress I'd like to explain why.
All of the core developers currently cant dedicate reasonable amounts of time to pida.
Ali started working for Google and is still waiting for some legalizing papers
... [More]
wrt his open-source work outside of Google.
Daniel has a huge workload in his studies and limited his open-source time to ulatencyd,
which is supposed to save us from painful issues like the swap of death when building pypy.
Ronny has picked up working on pypy and pytest and is preparing to start his diploma thesis.
Ali and Ronny plan to pick up more time-frames for pida early in the next year,
Daniel will be occupied longer.
[Less]
|
|
Posted
about 16 years
ago
by
ronny
I'm pleased to announce the release of pida 0.6.2,
over 100 changes accumulated and pida got faster.
changelog since 0.6
switch to hgdistver
switch back to setuptools
kill our build_doc command, build_sphinx works
bump the required python version
... [More]
to 2.6
settings are now stored using stdlib json
puilder uses stdlib json
window state is now stored in json
add execnet/py to the depends
port the nosetest plugin from dbus to execnet
remove the last uses of the gtkforms module for pygtkhelpers
fix up various transition-leftovers of the kiwi to pygtkhelpers switch
ignore locales/translations for now
switch to the most recent anyvc api
use the real bpython-gtk since its availiable now
beef up various core datatypes
remove document.unique_id
kill the buffer list markup helpers in document
move indexer functionality from project to a dedicated type
kill the bugtracker service since we dont use launchpad any more
bugfixes in the trac plugin (thanks Christopher)
remove all parts of pida.utils.gthreads we have in pygtkhelpers
remove the gtkhtml fallbacks of browseweb - webkit is the future
removed the document encoding from the statusbar
kill the PidaGladeView? alias
better logging of service failures
fix incorrect handling of missing libs on startup
fix project removal (#411)
revise the internal resource-finder
[Less]
|
|
Posted
over 16 years
ago
by
ronny
Recently the plugin/extension mechanism of great projects like py.test and flask have been an inspiration for minimalism and simplicity as well as for lack of painful labor.
The conclusion was quite a bummer - writing pida plugins is rather
... [More]
painful, full of seemingly unnecessary labor and not quite pythonic.
So we decided to try and take ideas from py.test and flask to reshape how plugins are written.
The target is clear - less labor, more fun, less dealing with dozens of dozens of classes.
[Less]
|
|
Posted
over 16 years
ago
by
ronny
After quite some struggle the last few years
and many refactorings im proud to finally
give the long overdue pida 0.6 series to the world.
The larges changes are
new plugin system
new core ui framework based on pygtkhelpers
the first iteration of
... [More]
a language plugin system
thats supposed to ease adding outlining/validation/completion
for new languages
a completely rewritten vim integration
that leverages dbus for communication with vim
and finally handles new unnamed files propperly
This release is also supposed to be the beginning of a workflow around more continious integration based workflow.
In the months to come we'd like to automate the release and testing process,
so we can just lay back, and releasing of pida and the in-source tree plugins will be a process governed by automated testing and accumulation of change.
The long period of non-stable-releases has very been a pain foer users and the team.
We really don't want to repeat that.
Instead we begin to try end release every few changes that enhance the user experience.
[Less]
|
|
Posted
over 16 years
ago
by
ronny
As of yesterday i pushed about 150 changes to main.
The most important change is the removal of our dependency on kiwi,
we worked hard to build the replacement named pygtkhelpers.
I also got around merging Bernhard Leiner's restructured-text
... [More]
plugin,
which is a very good start providing a outliner and a validator for plain restructured-text as well as sphinx extensions.
Also we recognized a few new needs.
Plugins now need proper custom per-project options in terms of api and ui
(for example the sphinx base for the restructured-text one).
Also we really want to run outliner and validator plugins on jit-ed python interpreters i.e. cpython+psyco/unladen swallow/pypy-c-jit.
And of course, not to forget giving access to the java platform via jython.
The next step will be to decide if any of those should be done before the 0.6 release.
[Less]
|
|
Posted
over 16 years
ago
by
ali
So, the Python standard library. Batteries Included. Pretty cool, huh? Yes, it's brilliant. I wouldn't be half the hack I was if not for those classic libraries like urllib.
But my expectations of Python have matured over the years, and these days
... [More]
I don't worry about dependencies, and just import whatever I can. Often I use a different library because it has features, performance, or I just prefer the API.
This is a list of libraries that I would never use the standard library equivalent.
Standard LibraryReplacementNotes
xmllxml
optparseargparse
asyncoreTwisted
string.TemplateJinja2
os file/path functionspy.path
unittestpy.test
ConfigParser?pyyamlNot strictly, but why anyone would ever use an ini file
wsgirefWerkzeugOk, granted wsgiref was never meant to be anything other than a reference implementation, but just remember not to use it
Here is a list of libraries who's functionality should be in the standard library, but isn't
FlatlandGeneric schema flattening/validation/coercion/rendering
SqlAlchemy?RDBMS Access
[Less]
|
|
Posted
about 17 years
ago
by
poelzi
We are proud to announce the last beta of Pida 0.6.
If no severe bugs will show up, Pida 0.6.0 will be release in the next two weeks. Please report bugs you find here.
It was a long time since beta2 and a lot of changes happened since then:
Core
... [More]
Highlights
multiprocessing language plugins
Language plugins can now use a multiprocessing infrastructure which allows expensive operations to be done on other cpu cores. This increases the speed of plugins like python_lint and python dramatically and do not make the gui sluggish anymore.
project file caches
Projects now have a filecache which allows fast queries to filenames and filetypes. The QuickOpen? plugin provides a gui for this, allowing the user to open files to which parts of the name, path or filetype is known easily
very precise feature selection from LanguagePlugins?
better filemonitor support
new documentation (needs some gui work tho)
lot of speedups
lot of usability enhancements
lots and lots of fixes
New Plugins
RegexpToolkit? - helps you develop and analyze regular expressions
QuickOpen? - fast file opener for project files
WayPoint? - autogenerates waypoints when you surf and edit files and allows to jump back and forth
[Less]
|
|
Posted
about 17 years
ago
by
poelzi
As Pida was started, there where two choices for the Toolkit in use. Gtk and Qt3 where available and gtk was the better choice at that time.
The years passed and so did the choices changed. The development on Gtk was rather slow compared to Qt and
... [More]
with the Qt4 a really major step was done which shifted the best choice to Qt.
Also looking at the available text widgets the choices are even more clear. GtkSourceView? got only very little improvement while with kate and other widgets are getting much improvement — while development on medit started stalling.
Now, while we are at it, why switch from one toolkit to another and not use the oportunity to make things right. So, the overall plan is to separate the gui elements from the logic first, and then start implementing a second gui in Qt.
With the XEmbed support in both toolkits, it as already possible to mix widgets with each other, but using it is rather ugly. For example can widget not be reparented without breaking the connection, but both run in the same main loop, which is a good thing.
As Qt does not provide such a cool widget as we use for the main window currently, this needs to be implemented first. Best would be in C++ so other projects could use it, too.
Investigation showed however, that it seems not to be impossible that a real mixing of widgets can be accomplished. We are already in the same mainloop on a X-Server at least. The best thing would be if we would find a way to use gtk widgets in a qt application.
This redesign is planned for the 0.7 release and 0.6 will become a long living gtk branch.
[Less]
|
|
Posted
about 17 years
ago
by
poelzi
The website got some face-lifting recently.
Changing to a trac only site allows us to easier manage the site. Also the site moved to a new server so things might be broken.
|
|
Posted
about 17 years
ago
by
poelzi
News about Pida
|