Fixed!
On Tuesday 21 March 2006 07:08, Sander Hoentjen wrote:
> [16:07:25] -----------------------------------------
> [16:07:25] >>> GOT TCL/TK ERROR : {{invalid command name
> "::plugins::findplugins"}}
>
> >>> Stack:
>
> invalid command name "::plugins::findplugins"
> while executing
> "::plugins::findplugins"
> (procedure "::plugins::UpdatedPlugins" line 5)
> invoked from within
> "::plugins::UpdatedPlugins"
> (procedure "::autoupdate::UpdateLangPlugin" line 10)
> invoked from within
> "::autoupdate::UpdateLangPlugin"
> (procedure "::autoupdate::check_web_version" line 54)
> invoked from within
> "::autoupdate::check_web_version $token"
> ("eval" body line 1)
> invoked from within
> "eval $state(-command) {$token}"
> ("eval" body line 12)
> invoked from within
> "eval ::error $errorlist"
> (procedure "http::reset" line 11)
> invoked from within
> "http::reset ::http::1 timeout"
> ("after" script)
>
> >>> Code: NONE
>
> [16:07:25] -----------------------------------------
> [16:07:25] >>> AMSN version: 0.96b - AMSN date: 12/22/2005
> [16:07:25] >>> TCL version : 8.5a3 - TK version : 8.5a3
> [16:07:25] >>> tcl_platform array content : byteOrder littleEndian
> osVersion 2.6.15-1.1955_FC5 platform unix machine i686 threaded 1 os
> Linux wordSize 4 user tjikkun
> [16:07:25] -----------------------------------------
>
> On Sun, 2006-03-19 at 22:09 -0800, Karol Krizka wrote:
> > Hi everyone,
> > Over the past week I worked on the plugin system and improved it a it.
> > Here are sme notes.
> >
> > RegisterPlugin
> > This was quite a useless proc because all it did was add the plugin to
> > known plugins and was required to be called every plugin. So I figured
> > that it might be a good idea to have the proc executed autmaticily after
> > the plugin is loaded. This will also allow the plugin not having to
> > unregister itself if it fails loading. For example like the chameloen
> > plugin is doing now.
> >
> > knownplugins
> > This basically held names of plugins that are loaded or were loaded in
> > previous life. There are two other variables that hold this information.
> > loadedplugins has a list of currently loaded plugins and ::*_cfg are
> > configs of previously loaded plugins. So to get rid of this duplication,
> > I removed knownplugins list.
> >
> > ::*_cfg
> >
> > This was seveal arrays in the global namespace that held the config of
> > previously loaded, but now unloadd pluins. Two probems i saw with this
> > were that (1) it is in th global namespace and (2) hard to keep track of
> > because there was a different one for each plugin. So first I moved it
> > into ::plugins:: and sencond I created a single array called "config"
> > which has names of plugins as keys and the value is it's config as a list
> > (via "array get")
> >
> > restoring config in LoadPlugin
> > Currently old configuration is restored after the plugin is initialized
> > because the default config is created in the init proc. I was thinking
> > what if the plugin initialized with needing somehting from the
> > configuration? So wouldn't it better to have the config set outside any
> > proc and then restore the configuration before calling the init proc?
> > What does everyone think?
> >
> > ::plugins::getInfo plugin param
> >
> > New proc that returns the parameter that is set inside plugininfo.xml.
> > The parameter has to be exactly as the name of the tag inside the file.
> > If such a parameter is not found, The proc returns blank.
> >
> > All my changes shouldn't break compability with any of the plugins. If
> > you find something that does please tell me and I will try to fix it. I
> > will also announce this on the forums for those that want to get a head
> > start developing plugins for 0.96 after my changes have been disscussed
> > here on the mailing list.
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel-- Karol Krizka
pgpYC6BU9sbX5.pgp
Description: PGP signature
