octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #39479] 'pkg -forge list' takes 56.5 seconds


From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #39479] 'pkg -forge list' takes 56.5 seconds
Date: Fri, 22 Mar 2019 19:03:53 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36

Follow-up Comment #19, bug #39479 (project octave):

> When do we replace pkg by octave-packajoozle? ;-) Looks great, I just tested
it! 

Aw, thank you!

> Unfortunately you are no student for GSoC, right? ^^ Recently, "Dildar Sk"
decided to work on improving pkg. 

Nope, I'm a 40-year old grizzled veteran hacker. :)

> I think another competing from scratch approach will not be beneficial.
Maybe he can help documenting and merging your code into Octave core for 6.0?

I think so too. If this is going to become part of core Octave, it will need
some real help, because the pkg code is so central and widely used; it has to
be robust. And if I understand it correctly, this would be the first major
Octave feature to make use of Octave OOP, so it would need both testing and
documentation of both the classes and OOP techniques it uses. I think that
could be a good GSoC project. It could involve:

* Testing, both interactive and setting up test scripts and harnesses
* Documentation: getting the Packajoozle documentation into a shape where a
GSoC student could understand it and effectively work with the code would be a
good demonstration of its documentation and design.
* Dependency resolution code. The current dependency resolution logic is
rather naive, and dependency resolution is complicated. Developing real,
robust dependency resolution could be a good part of a summer project.
* Working with Octave to fix issues with the classdef/OOP support (like bug
#55976 and bug #55810). There seem to be some basic shortcomings in object
support; I'm guessing this is because people don't use it very much?
* Developing a public API for the Packajoozle objects. Right now, they're all
in +internal, but I'd like to present a public OOP API for developers that
want to script or extend package management.
* Shepherding Packajoozle through the process of becoming an Octave Forge
package, so people can use and test it, on its way to getting into core
Octave.
* Making sure it works on Linux and Windows
* Getting rid of weird errors and warnings, like complaints about missing
paths after a package has been installed
* Integration with Testify or the core BIST code, so `pkj test <package>`
works well, and we can run scripts that test all the Octave Forge packages
* Support for additional, temporary package installation directories besides
the regular "global" and "user" ones, so that package testing can be done in a
clean installation space and not mess up the user's existing package
installations.

Though I'm having enough fun with this myself, who knows how much of that I'll
get done by the time GSoC starts.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?39479>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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