https://sourceforge.net/p/yorick/feature-requests/Recent changes to feature-requestsenTue, 24 Apr 2007 17:10:02 -0000https://sourceforge.net/p/yorick/feature-requests/3/<div class="markdown_content"><p>Can your software implementation benefit from this design approach?<br /> <a href="http://en.wikipedia.org/wiki/Aspect-oriented_programming" rel="nofollow">http://en.wikipedia.org/wiki/Aspect-oriented_programming</a></p></div>Markus ElfringTue, 24 Apr 2007 17:10:02 -0000https://sourceforge.netb5e41642746e7c5f5530cebe43ef57fcc96c576dhttps://sourceforge.net/p/yorick/feature-requests/2/<div class="markdown_content"><p>Where from is it possibile to get the binaries for Windows ?<br /> M.Trifon (mtrif@katamail.com)</p></div>AnonymousWed, 04 Apr 2007 12:34:59 -0000https://sourceforge.net86e528b23592d48502f0d8cb7b95fda40f11e8c0https://sourceforge.net/p/yorick/feature-requests/1/<div class="markdown_content"><p>Hello,</p> <p>currently, issuing <br /> autoload, ifile, vari<br /> where VARI has already been defined as an autoload<br /> variable yields an error:<br /> ERROR (*main*) autoload variable must be nil initially</p> <p>This makes it harder for e.g. a user to install a more<br /> recent or modified version of a plugin that is already<br /> installed system-wide.</p> <p>I think the right behavior would be for the second<br /> definition to override the first one, perhaps with a<br /> warning when the new autoload does not refer to the<br /> same IFILE.</p> <p>This occured to me as I was trying to design a<br /> reasonable framework for installing plugins through<br /> mixed systems, i.e. the OS-level package manager and<br /> yorick's pkg_mngr, and into several trees (e.g. OS<br /> level and user level). I won't detail here, but it<br /> looks like this issue with the autoload mechanism is<br /> the last remaining difficulty towards a robust and<br /> user-friendly system.</p> <p>Regards, Thibaut.</p></div>ThibautSat, 29 Apr 2006 09:26:25 -0000https://sourceforge.net9bcb4f2f6a49ddd7cf773ff24dc21167d8a080a1