#1439 closed defect (fixed)
make install_package('...') through the notebook far less verbose
Reported by: | was | Owned by: | was |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | packages: standard | Keywords: | |
Cc: | was | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
Background:
On Dec 9, 2007 1:00 PM, root <daly@axiom-developer.org> wrote: > >The main plus of this packaging for sage is that it builds from > >source quickly (in a few minutes) using precompiled clisp files. > > Well, on my 2Ghz machine with 2 Gig of memory running VMWare and > using the sage vmware image (but upgrading the VM to have 1G memory) > I started the package-install at 3:30am this morning. It is now > 2:10pm and the build is still "in-process". They are heavy things, > your minutes :-) On a 1.8Ghz opteron (sagemath.org) it takes 18 minutes (I just tested the install). I am completely baffled that it would take > 11 hours to install into vmware under windows. I'll look into that next time I get a chance to use windows (in my office). Thanks for reporting the problem. > Likely a portion of the problem is due to starting the package-install > from the notebook. I'm running native windows and sage in the VM and > connecting thru the browser. That is very likely the problem. The output of installing packages through the notebook is way too verbose, so this is in fact a likely source of the problem (which could be remedied). Better would be to login as "manage" and type "sage -i fricas-0.3.1". > I suspect a lot of CPU is going into running jsMath to redraw the > output page. The Fricas build has a lot of output (which could be > suppressed during package-install) and jsMath is not fast. Axiom > has a NOISE variable in the Makefiles to suppress most output. Excellent. > You might consider a note suggesting that installs be done from > inside the virtual machine rather than thru the notebook interface. Better would be to fix things so they work through the notebook well.
The fix would likely be to execute the update command, but pipe everything to a file, and include a link to that file in the output (so one can look at it and press refresh in the browser to test status).
Change History (8)
comment:1 Changed 15 years ago by
comment:2 Changed 14 years ago by
- Summary changed from (EASY) make install_package('...') through the notebook far less verbose to [Bug Day Material] (EASY) make install_package('...') through the notebook far less verbose
comment:3 Changed 14 years ago by
comment:4 Changed 12 years ago by
- Cc was added
- Report Upstream set to N/A
- Work issues set to Close/mark as fixed?
Doesn't seem to be a problem anymore. Close?
comment:5 Changed 12 years ago by
- Milestone changed from sage-4.3.1 to sage-duplicate/invalid/wontfix
- Resolution set to fixed
- Status changed from new to closed
Works with sagenb-0.6
comment:6 Changed 12 years ago by
- Milestone changed from sage-duplicate/invalid/wontfix to sage-4.3.1
comment:7 Changed 12 years ago by
- Summary changed from [Bug Day Material] (EASY) make install_package('...') through the notebook far less verbose to make install_package('...') through the notebook far less verbose
comment:8 Changed 7 years ago by
- Milestone changed from sage-4.3.1 to sage-duplicate/invalid/wontfix
- Work issues Close/mark as fixed? deleted
Note: See
TracTickets for help on using
tickets.
This confirms my hypothesis...