slime-devel December 2003

slime-devel@common-lisp.net

52 participants
93 discussions

[slime-devel] completion broken?
by Sean O'Rourke 03 Dec '03

03 Dec '03

Was anyone else having problems with minibuffer completion? The problem I'm seeing is that slime-completing-read-internal returns "((choices) best)" but its callers seem to expect just "(choices)". Anyways, this patch fixes that, and removes an extra paren in slime-documentation. /s

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 03 Dec '03

03 Dec '03

Index: slime/ChangeLog diff -u slime/ChangeLog:1.131 slime/ChangeLog:1.132 --- slime/ChangeLog:1.131 Mon Dec 1 20:33:14 2003 +++ slime/ChangeLog Tue Dec 2 09:02:03 2003 @@ -1,3 +1,25 @@ +2003-12-02 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-sbcl.lisp (find-function-locations): Return a non-empty + list of source locations. + + * slime.el (slime-with-xref-buffer): Remove spurious comma. (Bug + reported by Raymond Wiker). Some reordering of the xref code. + + * swank.lisp (documentation-symbol): New optional argument for + return value if the symbol is not documented. + +2003-12-02 Sean O'Rourke <sorourke(a)cs.ucsd.edu> + + * slime.el: (slime-repl-{clear-buffer,clear-output}): clear the + last and entire output in the *slime-repl* buffer + (slime-documentation): pop up a buffer with a symbol's + documentation instead of its description, if found. + (slime-complete-symbol): tweak to completion, taken from ilisp, to + complete filenames inside strings. + (slime-set-default-directory): also set *slime-repl*'s + default-directory, so e.g. find-file makes sense. + 2003-12-02 Daniel Barlow <dan(a)telent.net> * slime.el (slime-with-xref-buffer): moved further up the file so

1 0

[slime-devel] US STOCK MARKET - HTDS Medical Research---CANCER Trials.....charis
by Keisha Case 02 Dec '03

02 Dec '03

US Stock Market - Stock Profile of the Week Symbol: HTDS Market: PK Sector: MEDICAL RESEARCH BARCHART Rates HTDS an 80% BUY - http://quotes.barchart.com/texpert.asp?sym=HTDS Before we begin our profile we have very exciting, breaking news... Tubercin Passes Toxicity Trials - Ready To Proceed To Live Cancer Trials BREAKING NEWS - DELRAY BEACH, Fla.--(BUSINESS WIRE)--Hard to Treat Diseases Incorporated (Pink Sheets:HTDS) announces that Tubercin® has passed the toxicity tests required to proceed to the live cancer trials. Testing Tubercin® on live Melanoma, Lung and Breast cancer cells will begin immediately. The President and CEO, Mr. Colm J. King, met with the spokesperson of the medical group at their offices in Oklahoma City. Mr. King was advised that the tests were conducted under strict FDA (Federal Drug Administration) guidelines. Full test results will be available at the corporate offices as soon as the reports and findings are printed. "These are the most promising results to date regarding Tubercin® and we're looking forward to additional positive results in the near future," stated Mr. King. "These tests prove that Tubercin® is non-toxic and is the first step on the way to human clinical trials as well as the first positive breakthrough conducted in the United States with an independent medical group for Tubercin®." Operating out of Delray Beach, Florida, Hard to Treat Diseases Incorporated ("HTTD") holds the international marketing rights, except South Korea, to Tubercin®, a patented immunostimulant developed for combating Cancer under medical patent (US Patent 6,274,356). The unique properties unlike other cancer products are clearly stated in the abstract summary of the patent... "A carbohydrate complex, which is a mixture of low molecular-weight polysaccharides of an arabinomannan structure extracted from Mycobacterium tuberculosis, is highly effective in treating various cancer patients without incurring any adverse side effects." STOCK PROFILE OF THE WEEK HTDS is now at an emerging and potentially explosive stage. As stated in their press release, Tubercin is now ready to proceed (after tests conducted under strict FDA guidelines) to human clinical trials. While they have jumped one very big hurdle, they are still in the early stages of development and now is a great time for investors to take heed. TUBERCIN Over the past ten years, epoch making anticancer agents have continuously been introduced, but the mortality of cancer patients have been rising in the U.S. and the European countries not to mention Japan and Korea. The decisive measure to cope with cancer is surgery. When the cancer cells spread throughout the body instead of remaining on the original spot, the treatment should take into consideration chemotherapy, radiation therapy and immunotherapy. The drawback of such therapies, however, is they incur damages not only on cancer cells, but also on the normal cells. Chemotherapy and radiation therapy are not suitable for application on weakened patients, especially those above 70. Historically, various forms of immunotherapy have been performed, falling short of therapeutic expectation. When Bacille calmetteguerin is used as an active no-specific immunotherapeutic agent, however, the patient's prognosis turns better through a simulative action on immune system of the cancer case. Professor T.H. Chung of Korea extracted carbohydrate complex Tubercin from microbacterium tuberculosis to be used as immunostimulant. This was meant to activate the T-lymphocyte of the cancer patient to produce lymphokine. This process strengthened and promoted immuno surveillance activities in deficient state and alleviated the pain and prolonged the life of cancer patients. Of late the pharmaceutical industry in advanced countries started to put on the market so called cancer vaccines (active specific immunotherapy). The vaccines, bacterial extracts, as adjuvants, with autologous and or allogenic cancer cells to generate antibodies to cancer cells, facilitating the killer T-cells to recognize and destroy cancer cells. The laboratory work to modify autologous or allogenic cancer cells are not ordinary and simple. When our lab work augments the active specific immunotherapeutic agents, the Tubercin will be one of the best adjuvants. Meanwhile, the main point of AIDS is its virus killing T-cells and Tubercin helps maintain healthy T-cells. Consequently, we focus our effort on the application of Tubercin to AIDS. TUBERCIN is derived from micro bacterium tuberculosis. As an immunostimulant, TUBERCIN strengthens the human body's own immune system and assists the body in seeking out and combating cancer cells. HTTD is potentially able to develop TUBERCIN into a low-cost product to treat cancer patients on an international scale. Salient treatment, through the administration of TUBERCIN, could positively affect thousands of lives in North America. In addition, Europe and Asia have millions of lives at risk each year because of viral diseases such as cancer. TUBERCIN IS A FINISHED PRODUCT. Tubercin as an inmunostimulant has been administered to human patients in stages three and four of terminal cancer. There have been no indications of any adverse side effects in human trials There has been encouraging results of patients with TUBERCIN in the last fourteen years. Various forms of cancer were involved and many of the patients survived. A review of clinical studies indicate TUBERCIN has no side effects and could possibly be administered in conjunction with other such modalities for the treatment of cancer without any adverse effects. The scientific presumption would be the distinct possibility of a strengthened immunity system and the administration of treatment such as chemotherapy at the later stages of tumor growth would not be impeded by the weakened condition of the terminal cancer patient. To this end the Company has been assisted by outside consultants reviewing the research data and human trials involving TUBERCIN to see specifically whereby incidents of dual treatment produced favorable results in terms of moving toward indication of prolongation of the life of the cancer patient. There is recognition that morphine is an trusted pain killer, but in totality it cannot be said that it has no side effects. In the maintaining of patient care, there is the strong possibility that TUBERCIN could be also considered as a candidate for a pain management. The Company's scientists describe TUBERCIN as having the high propensity of deadening the nerve endings in specific areas of the body where cancer has caused erosion and consequently much pain. PATENTS Presently, HTTD has the patent rights for Korea, Japan and the United States. The Korean patent was issued on October 29, 1998 (Registration No. 173362). The Japanese patent was issued on June 12, 1998 (Registration No. 2790447). The United States patent was issued on August 14, 2001 (Registration No.6,274,356). Currently, patents are pending for Canada and Europe (the United Kingdom, France, Germany, Italy and Spain). CANCER IN OUR TIME In the 20th century, the number of cancer patients has been on the increase. Although many anti-cancer agents were developed and an enormous study on its essence continued, the mortality by cancer still is increasing. Mankind may be chronically threatened with cancer in the 21st century. Nine million new case of cancer occur annually and five million people die from breast cancer, reports the World Health Organization. Dramatic increases in life expectancy and change in lifestyle are estimated to increase the number of new cancer cases to 20 million annually by 2020 and cancer deaths to more than 10 million. About 552,200 Americans - more than 1,500 people a day - are excepted to die of cancer this year. In the United States, one of every four deaths is attributed to cancer. Cancer is the second-leading cause of death in the United States. Exceeded only by heart disease. About 5 million lives have been lost to cancer since 1990 and about 13 million new cases have been diagnosed. In 2000, more then 1.2 million new cancer cases are expected to be diagnosed. The number of cancer cases will continue to grow, spurred by the aging population. By 2009, this patient group could total 8.4 million. In 1997, about 6.3 million people worldwide died from some form of cancer, and most major international cancer agencies expect this number to double by 2022. Please note that HTDS had absolutley nothing to do with this report and is not a participant in any way. No more advertisements: http://doubleopt.biz/optout.html Stock Market Today is an independent research firm. This report is based on Stock Market Today's independent analysis but also relies on information supplied by sources believed to be reliable. This report may not be the opinion of HTDS management. Stock Market Today has also been retained to research and issue reports on HTDS. Stock Market Today may from time to time purchase or sell HTDS common shares in the open market without notice. The information contained in this report shall not constitute, an offer to sell or solicitation of any offer to purchase any security. It is intended for information only. Some statements may contain so-called "forward-looking statements". Many factors could cause actual results to differ. Investors should consult with their Investment Advisor concerning HTDS. Copyright 2003 © Stock Market Today Ltd. All Rights Reserved. This newsletter was distributed by MMS, Inc. MMS was paid eight hundred and fifty thousand shares HTDS stock to distribute this report. MMS is not affiiated with Stock Market Today and is not responsible for newsletter content. jycbdyvqrv kzmdmneq sxacruncmferhs sgzglxg uqn mhfdzevi x hc

4 3

[slime-devel] Possible typo in slime-with-xref-buffer
by Raymond Wiker 02 Dec '03

02 Dec '03

I'm getting errors when trying to byte-compile slime.el. I *think* this is because of a spurious comma in slime-with-xref-buffer; patch below. cvs server: Diffing . Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.124 diff -u -r1.124 slime.el --- slime.el 2 Dec 2003 01:33:14 -0000 1.124 +++ slime.el 2 Dec 2003 10:04:40 -0000 @@ -3009,7 +3009,7 @@ (slime-init-xref-buffer ,package ,type ,sym) (make-local-variable 'slime-xref-saved-window-configuration) (setq slime-xref-saved-window-configuration - ,(current-window-configuration))) + (current-window-configuration))) (progn ,@body) (setq buffer-read-only t) (select-window (or (get-buffer-window (current-buffer) t)

2 1

[slime-devel] miscellaneous small additions
by Sean O'Rourke 02 Dec '03

02 Dec '03

This patch adds a few minor tweaks I found useful: * slime-repl-{clear-buffer,clear-output}: clear the last and entire output in the *slime-repl* buffer * slime-documentation: pop up a buffer with a symbol's documentation instead of its description, if found. * tweak to completion, taken from ilisp, to complete filenames inside strings. * slime-set-default-directory: also set *slime-repl*'s default-directory, so e.g. find-file makes sense. /s

2 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 02 Dec '03

02 Dec '03

Index: slime/ChangeLog diff -u slime/ChangeLog:1.124 slime/ChangeLog:1.131 --- slime/ChangeLog:1.124 Sun Nov 30 03:20:40 2003 +++ slime/ChangeLog Mon Dec 1 20:33:14 2003 @@ -1,3 +1,45 @@ +2003-12-02 Daniel Barlow <dan(a)telent.net> + + * slime.el (slime-with-xref-buffer): moved further up the file so + it's defined before slime-show-xrefs needs it + + * swank-sbcl.lisp (function-source-location-for-emacs): return a + list of source locations (one per method) when the request is + for a GF. This seems to make the elisp side popup a window + to let the user select one. Cool. + +2003-12-01 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-[cmucl,sbcl,openmcl,lispworks].lisp (invoke-nth-restart): + Use invoke-restart-interactively. + + * slime.el (slime-create-note-overlay, slime-sexp-depth): The + 'priority' property is unused. Remove it. + + * swank-openmcl.lisp (find-function-locations): Return all methods + for generic functions. Doesn't work very well if multiple methods + are in the same file. + (swank-accept-connection): Don't create an extra thread, call + request-loop directly. + +2003-12-01 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-repl-return): Goto end of input area before + inserting newline. + (slime-autodoc-message-ok-p): Test to see if a documentation + message should be printed (returns nil if the + minibuffer/echo-area is already being used). + (slime-symbol-at-point): Skip back over whitespace before + looking for the symbol. + (slime-autodoc-delay): New configurable to specify the delay + before printing an autodoc message (default 0.2 secs). + (slime-ensure-typeout-frame): New function to call create a + typeout frame unless it already exists. Suitable to run on + slime-mode-hook if you always want to have a typeout window. + (slime-log-events): When nil, don't log events to + *slime-events*. This works-around a problem Raymond Toy has when + starting SLIME under XEmacs. Still investigating.. + 2003-11-29 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * slime.el: Rewrite the xref code to work with other source

1 0

[slime-devel] Re: [Ilisp-devel] SLIME
by Bill Clementson 02 Dec '03

02 Dec '03

Luke Gorrie <luke(a)bluetail.com> writes: > Bill Clementson <bill_clementson(a)yahoo.com> writes: > > > Even if the eventual goal is to replace all the functionality that > > is provided by ILM/ILISP, ILISP would provide more "short-term" > > benefits for the SLIME CL developer than ILM would. > > That would have been one way, but we went the clean-room approach. We > only use ILM to start Lisp and compile our server, and *inferior-lisp* > as a debugging fallback. We've covered all the major features now, > although there's plenty of hacking left to do to get all the details > right and support everyone's favourite add-ons. > > Starting from scratch means more work/fun, but it also gives us a > fresh codebase. To an outsider, some of the code in ILISP is slightly > terrifying :-), as in any program with such a long Actually, to an insider, some of the code in ILISP is a bit terrifying too ;-) > history. We also > wanted to do most things differently and to have an environment more > like the elisp one, so it would only give us a head-start in the > short-term. > > ELI really doesn't appeal to my hackstincts. From the web I can't even > tell who wrote it, Steve Haflich (of Franz) was the author of the very first version of ELI back around 1987. Since then, a number of different Franz hackers have contributed to it. > and most questions on groups.google.com seem to go > without definitive answers. I'm not sure which group you're referring to. As far as I'm aware, there is no Franz/ELI mailing list on groups.google.com. If you're referring to comp.lang.lisp.franz, I'm not surprised as that newsgroup is just about dead - most Franz-specific issues seem to be either directed to c.l.l. or to the allegro-cl mailing list, both of which are very active and both of which you can generally get a quick reply from. > I downloaded my copy from Neil van Dyke's > website, which says "Please do not pester Franz to support this > packaging, lest they regret GPL'ing." > > It looks like Franz did the least necessary to be allowed to link with > Emacs under the GPL, and would be unlikely to let a dozen random > hackers into their CVS tree :-) so that is a potential dead-end. That is a bit unfair. I have personally worked with both Steve Haflich and Kevin Layer on various ELI enhancements and have worked with a number of other Franz employees on other ACL issues. I have always found the Franz people I've dealt with to be very receptive to suggestions as well as terrific programmers. I doubt that you would get better responses to requests or suggestions for improvements at many open source projects. I should also mention that I am not a licensed ACL user either. > So I think our approach is pretty reasonable. We'll see how it > goes. I'm even hoping we can tempt some of you fine hackers to have a > play around on the dark side ;-) I already mentioned that I use MS Windows - doesn't that qualify me as playing on the dark side already ;-) > And of course my views do not necessarily reflect those of the other > SLIME hackers, Aha, now come all the caveats: don't remove the label, not valid with other offers, use before expiration date, etc, etc :-) > but I hope this answers this thread's main > question. Note however that this is almost entirely after-the-fact > rationalization. Really, it was just too addictive to stop. ;-) Sorta like having a pint, eh - you can't just have one :-) -- Bill Clementson __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

[slime-devel] Slime disconnect evaluation region/buffer
by gharvey＠nf.sympatico.ca 02 Dec '03

02 Dec '03

This shows up with linux 2.4.18, cmucl 18e and up to date anoncvs slime; the problem is that every time you send a buffer larger than 4092 bytes, read-sequence will only get the first 4092. I've attached a fix that works for me, but might not be the best solution in the case of an actual network connection. The change basically adds read-sequence-fully, and modifies read-next-form to use it. -- Greg

2 1

Re: [slime-devel] Daily ChangeLog diff
by Sean O'Rourke 01 Dec '03

01 Dec '03

Sean O'Rourke <sorourke(a)cs.ucsd.edu> writes: > Luke Gorrie <lgorrie(a)common-lisp.net> writes: >> + (slime-autodoc-mode): New command. > > I think we're losing here by rolling our own instead of using eldoc. > For example, today I noticed that slime-autodoc continues to echo > during an isearch; eldoc has been made to avoid doing this. Sorry, slip-of-the-finger plus Gnus' send-without-confirm behavior led me to send the incomplete message above. To continue... In slime-autodoc's favor, it _is_ much simpler, particularly when you consider having to use an advice to take advantage of eldoc in pre-21.3 Emacs. But I suspect that there will be other cases of unforseen gotchas and minor behavioral differences in the future, and can't help but think that maintaining a parallel implementation of eldoc is more trouble than necessary. /s

3 4

[slime-devel] Re: [Ilisp-devel] SLIME
by Bill Clementson 01 Dec '03

01 Dec '03

> Nicolas Neuss <Nicolas.Neuss(a)iwr.uni-heidelberg.de> writes: >> I would have preferred the option of LEP being supported by the free Lisp >> implementations (CMUCL, SBCL, CLISP, GCL). > David Lichteblau is working on this for SBCL. He shares code with > SLIME, since Dan is factoring all the SBCL-deep-magic code into the > SB-INTROSPECT library that we both use. > His LEP-for-SBCL is at http://www.lichteblau.com/src.html >> Is LEP too complicated or otherwise bad, so that SLIME became >> necessary? >Absolutely not. Interesting, I wasn't aware that there was any sharing going on between the SLIME and ELI-SBCL efforts. Since you are obviously talking to each other and aware of what the other is doing, how do you see the two efforts evolving? Do you think they will continue to be two separate efforts? If so, what segment of the SBCL developer community do you feel would gravitate towards SLIME as opposed to ELI-SBCL and why? In other words, why would an SBCL developer prefer SLIME over ELI-SBCL (or vice versa)? Cheers, Bill __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

4 9

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel December 2003