https://sourceforge.net/p/yorick/feature-requests/2007-04-24T17:10:02ZRecent changes to feature-requests2007-04-24T17:10:02Z2007-04-24T17:10:02ZMarkus Elfringhttps://sourceforge.net/u/elfring/https://sourceforge.netb5e41642746e7c5f5530cebe43ef57fcc96c576d

<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>

2007-04-04T12:34:59Z2007-04-04T12:34:59ZAnonymoushttps://sourceforge.net/u/userid-None/https://sourceforge.net86e528b23592d48502f0d8cb7b95fda40f11e8c0

<div class="markdown_content"><p>Where from is it possibile to get the binaries for Windows ?<br /> M.Trifon (mtrif@katamail.com)</p></div>

2006-04-29T09:26:25Z2006-04-29T09:26:25ZThibauthttps://sourceforge.net/u/paumard/https://sourceforge.net9bcb4f2f6a49ddd7cf773ff24dc21167d8a080a1

<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>