[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #41215] Request for a "pkg test" feature

From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #41215] Request for a "pkg test" feature
Date: Sat, 4 Jan 2020 17:29:03 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #30, bug #41215 (project octave):

While io just sets up a javaclasspath which might be harmless, other packages
may do things that could be more serious and shouldn't linger on. Stale
handles, communication channels, hardware connections, etc. come to mind.
But taking into account that it'll be merely developers that will run 'pkg
test' this might be less relevant.
It'll be moot anyway if bug #57535 gets fixed soon enough. Indeed, no reason
to hold here.

Being able to simply do 'path (oldpath)' is easy, but tracking what needs to
be removed from the path is also easy: it's just that part that got prepended
to the old path except ".". Figuring out the pertinent package names is a
one-liner cellfun. All in all it is just a few lines of code.

[A little OT]
Yep, pkg and friends look ridiculously complicated, but maybe we should be a
bit more forgiving. Once you get to think about all the concealed
complications, like e.g., nested and shared dependencies, and once you realize
that it dates from long before classdef, you soon get to appreciate why it is
as it is.

But as it stands, some detailed code is quite naive and could be much more
efficient and more concisively written, I give you that. Where I first left it
intact as much as I could, I recently started rewriting pieces where I was
working, if only to make debug-stepping more manageable.
A question I might raise on the maintainers list is why the package info is
kept in single structs in a cell array. That makes code unduly convoluted


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]