Richard Cook <rcook(a)llnl.gov&gt; writes: It probably can't find the EFS package, which is needed to download anything. What version of XEmacs is this? If it's 21.5, the packages need to go into share/xemacs, not lib/xemacs. If it's not (or problems persist), please run xemacs -debug-paths and post the output. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

I moved them to share and it worked. The instructions are incorrect on the web page. Probably a lot of the questions on this topic could be fixed if someone simply fixed that. :-) On Jul 27, 2010, at 9:56 AM, Richard Cook wrote: -- ✐Richard Cook ✇ Lawrence Livermore National Laboratory Bldg-453 Rm-4024, Mail Stop L-557 7000 East Avenue, Livermore, CA, 94550, USA ☎ (office) (925) 423-9605 ☎ (fax) (925) 423-6961 --- Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept. (opinions expressed herein are mine and not those of LLNL) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

True, but the instructions for the sumo tarball are not referencing beta anything, AFAIK. I'm serious that it should get fixed if so many people are complaining -- how hard is it to fix a word on a web page? :-) On Jul 27, 2010, at 10:16 AM, Michael Sperber wrote: -- ✐Richard Cook ✇ Lawrence Livermore National Laboratory Bldg-453 Rm-4024, Mail Stop L-557 7000 East Avenue, Livermore, CA, 94550, USA ☎ (office) (925) 423-9605 ☎ (fax) (925) 423-6961 --- Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept. (opinions expressed herein are mine and not those of LLNL) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

So, then we can add a sentence instead of a word. "If you are using the stable release, untar the sumo tarball into $prefix/lib/xemacs. If you are using the beta release, untar the sumo tarball into $prefix/share/xemacs". On Jul 27, 2010, at 11:00 AM, Rodney Sparapani wrote: -- ✐Richard Cook ✇ Lawrence Livermore National Laboratory Bldg-453 Rm-4024, Mail Stop L-557 7000 East Avenue, Livermore, CA, 94550, USA ☎ (office) (925) 423-9605 ☎ (fax) (925) 423-6961 --- Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept. (opinions expressed herein are mine and not those of LLNL) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Totally agreed on all counts. Make it work in both places, or better yet, just include sumo! Does having lots of packages in the release have any downside? Does it slow things down, introduce bugs, or what? On Jul 27, 2010, at 12:33 PM, Rodney Sparapani wrote: -- ✐Richard Cook ✇ Lawrence Livermore National Laboratory Bldg-453 Rm-4024, Mail Stop L-557 7000 East Avenue, Livermore, CA, 94550, USA ☎ (office) (925) 423-9605 ☎ (fax) (925) 423-6961 --- Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept. (opinions expressed herein are mine and not those of LLNL) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Richard Cook writes: This is an XEmacs distribution bug. You need the "efs" and "dired" packages, and "xemacs-base", to get anything done with packages. Unless you're really hurting for disk space, you should probably just download the "sumo" tarball from ftp://ftp.xemacs.org/pub/xemacs/packages and install it to $HOME/share/xemacs/xemacs-packages (I forget whether the tarball includes the /xemacs-packages/ prefix or not). That will give you pretty fresh packages all around, which you can then update. If you still have your MacPorts XEmacs installation, then EMACSPACKAGEPATH=/opt/local/share/xemacs $HOME/bin/xemacs & should give you a fully tricked-out XEmacs. Alternatively, ln -s /opt/local/share $HOME/share should do the trick. If you have problems with any of this, don't hesitate to ask. I'm pretty sure that's mostly right ;-) but I need to rush off to a meeting. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Andreas Röhler writes: Nobody's been crucified by this bug. 12; I'm counting. Are you going to fix it? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Andreas Röhler writes: When the packages were split out, EFS was considered an auxiliary package and places among the packages. This caused no problem at the time, because you had to explicitly fetch the sumo, and might as well use command-line FTP. Later, EFS was used to implement the package-ui stuff, and became a dependency. However, there is no real provision for including packages with the core, and EFS is a complex package with a separate maintainer. It wasn't considered appropriate to try to pull it back into XEmacs. No. 12 years is a long time, and there may not have been much discussion. Mike Sperber might remember better, being both involved in the design of the package sysrem and the EFS maintainer (then and now). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Richard Cook writes: Patches welcome. Some decision would need to be made about how to deal with an existing installation (remember, you currently can't download and install without efs installed, presumably in the usual place). "rm -rf" is the obvious solution but many users edit the packages directly; they'd lose their local changes. There's also the question of where to install which needs to be decided by the user in some cases; some interface would need to be provided for that. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: That's really not polite. M-x find-library means that users are quite likely to be unware of precisely where each library is. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: The polite way is not a policy. Making a policy is tempting because it's easy, but it's inappropriate here. OTOH, your other suggestion is plausible, but I haven't sufficient time to think carefully about whether it's really a good idea, let alone code it; no offense meant.:-) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Andreas Röhler writes: Yes. (1) Pulling packages back into core is not going to happen if I have anything to say about it. Ben's adventures in that area with one or two libraries have sucked. See my response to Richard for why this is a terrible idea in general. (2) Who's going to do the work? It was a huge amount of work taking man-years to unbundle the packages. Doing the reverse probably is much less work, but there's still a lot of work to be done. The system we have is workable. It can be improved incrementally, I agree, but I have more important things to do. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Andreas Röhler writes: Really? I really don't think so. We picked up two new potential developers in the last week. In any case, what's important to me is that it's not going to disappear from *my* screen any time soon, and therefore I'm going to work on what I need. If you think a course change is in order, submit patches and cooperate with requests from reviewers to improve them is the best thing to do. For the record, I believe that (1) people who are stopped by something as small as the allow-remote-paths bug or separate installation of XEmacs and the packages are extremely unlikely to become developers (2) ditto CUA keymap What's holding people back that's important: (1) We're a fork of a GNU project; politics makes GNU more attractive to a lot of people (and not a few in the other direction, but mostly to the extent it matters I think it works in GNU's favor). (2) We're not GPLv3 yet, and therefore most of our external packages and much internal code is behind GNU Emacs. I think the biggest costs are things like nxhtml, so we're not dead yet. (3) Emacs LISP is a crufty variant of a niche language. (4) Most elisp applications appeal to crypto-hacker types, rather than to ordinary users and developers. Lots of rough edges, not much flash. Much of the code is twisted and sucky. What we can do to attract new users likely to become developers (to some extent in order of importance): (1) release under GPLv3+, which will unblock packages and core code syncs. (2) Modernize elisp (Aidan's done a lot of Common LISP compatibility work; I would prefer a move toward Scheme, but since he's doing the work, I can only applaud). (3) Make XEmacs much more web-aware. Make URLs the standard input format for find-file for example (probably renamed to find-resource or retrieve-url or something like that). Get robust support for URL fetching (curl, neon, stuff like that) and editing (WebDAV). (4) More robust support for Unicode as such, and non-traditional characters in general (eg, spaces in file names). (5) GNU syncs, both in core and packages. (6) Large file support. (7) Better font support. (8) Improved ease of installation. (9) Exciting new features ... but that's for the new developers. :-) Personally, I intend to spend time on (1), (3), (4), and (7). (8) is way down the scale right now. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

Stephen, I right now am working through the allow-remote-paths problem, and in the process read an email that you wrote about a year and a half ago. I put your email at the end of this one, in case you don't have total recall of everything you ever wrote (grin). I guess I am a little discouraged right now, and I don't want that emotion to come through in this email, but I wanted to respond to two things you said (that are probably still relevant) and express my feelings about one other aspect of working on XEmacs. First, in your email you wrote: For the record, I believe that (1) people who are stopped by something as small as the allow-remote-paths bug or separate installation of XEmacs and the packages are extremely unlikely to become developers (2) ditto CUA keymap I hadn't realized that the allow-remote-paths was part of a_ new-developer-test_. I had a system crash, and all my /home was backed up, and all the default Slackware stuff was recoverable, but I had forgotten some applications that I installed recently. Like XEmacs 21.5. My mistake, so I am paying for it by chasing down everything and reinstalling/configuring. No problem. My first step after getting the message about allow-remote-paths was to get help on the variable name. But the variable name was not there. Tried the help on the menu which had different keystrokes and still not there. So I am pondering why some variables have help available and some don't. Mark it down to look it up later. Then I search for the error message online. Found the thread that your email was part of: http://list-archive.xemacs.org/pipermail/xemacs-beta/2010-July/019827.html And read the whole thing. I was a little put out about the fact that the package system was not part of the main XEmacs distribution at first, enough to get the rest of the packages at least, but then read the counter arguments (some from you) and was persuaded that the packages to install the rest of the package system probably should not be in the main distribution itself. But I, and others it looks like, still have this problem with allow-remote-paths. So I am asking myself while I am reading online, why do I have this problem. No I am not directing that thought outwards with the idea that other people are at fault. I'm asking myself why *I* have this problem and what is it that I do not know that is stopping me? Where should I be looking for help on what a variable is, other than the places I mentioned that I looked? Also asking why something like this does not have a more directed error message (a clue maybe) Do I now go wading through source code of XEmacs itself to find every occurrence of the error message? Is that what it takes to pass this step of developer-hood? No, don't rush off an answer about what is wrong. I will find it myself. I'm writing my thoughts to make a point, not get the answer given to me. I'm saying if the documentation was better, instead of written for a certain minimum knowledge of XEmacs stuff, it would put the cookies on the bottom shelf. What is missing in this case is 2 things: information, and a not-fully-formed flowchart in my head of how to solve a problem. Not fully formed because I am a beginner in all things XEmacs. I have written several thousand lines if elisp code in the past 2 years, so not a beginner at that, but a beginner in most other things XEmacs. And never contributed to an open source project before, so a beginner at version control programs, ssh keys and other stuff that is each piece of the puzzle named "how to contribute to XEmacs". First, information. I found a magnifying glass in the posts I read, to help me find the clue I need: XEmacs -debug-paths. That gives me a page of paths to different things. But the missing information is a simple ASCII chart that shows where XEmacs puts the various files. I have a clue in the -debug-paths output, but what should that output be? Where should things be kept for an XEmacs installation? You can tell me that it's over here (somewhere) but I cannot find it with the current organization of the web site/documentation. Probably bits of it are here and there, and probably (based on my experience) about as much misinformation (outdated, previous versions,etc) as good information. Now I am convinced that I not only need information, a better formed flowchart in my head, But a sifter as well, to sift the documentation for the various incorrect, or partially correct sentences in the documentation, that obscure complete understanding, or are correct but for some previous version. An example of the fog of documentation is the term sumo tarballs. I read and clearly remember the documentation saying we used to distribute sumo tarballs (and my first windows installation 8-10 years ago was such a tarball, source + packages), but we no longer distribute sumo tarballs, the editor and packages are separate. OK got it. But your thread that I read today said to download a sumo tarball. And unfortunately the link was broken (can't make you responsible for every change in things online, especially 1.5 years later). So the statement that we no longer distribute sumo tarballs is not correct, at least not completely. We distribute sumo tarballs still, but only of the packages, and those separately from the editor itself. Not I am not writing that to make you or anybody else responsible for every wrong thing that gets into my head. Or every distinction that I don't pick up on right away. But it is an example of things that stop beginning users. I'm reminded right now of the bumper sticker that says "Don't believe everything you think". Another example of the fog of documentation on installing XEmacs is found on this page: http://www.xemacs.org/Documentation/packageGuide.html it lists 2 required packages under installing automatically: EFS and XEmacs-base, and 2 optional packages. In the thread I found your emails in, you mentioned that dired needs to be be installed as well. It doesn't say that on the webpage I looked at, under installing by hand. So the fog is: does base include dired? Or is it a separate package they forgot to mention that now needs downloaded and installed as well? To be technical, there is no list of files under "installing by hand" that need to be downloaded and installed before packaging would work to do the rest; there is only an example of XEmacs-packages or mule-packages. For 21.4, not the current version. There is the note that was added closer to the top, that was referred to as a change, in the emails. But there is still the ambiguity of what files to install to get the package system up to install the rest. The categories are also not exactly clear: the section "installing by hand" could mean that you do not have to install the package system at all, but just install the packages you want by downloading/installing them by hand, or it could refer to the manual steps you need to take, installing a few packages before installing the rest automatically via the package system. I thought they were saying the latter, then later realized that the section "installing by hand" was probably talking about avoiding the packaging system entirely. The point I am making is that the "people who are stopped by something as small as the allow-remote-paths bug" don't have the tools to solve the problem, that is: -a fully formed lisp troubleshooting tree in their mind -an error message with a clue -correct unambiguous documentation to search for a clue a chart of where XEmacs wants to install files would be "bingo" for me now. Another point is that I think people who are experts on something don't still have their finger on the pulse of what trips up beginners, they forget what they didn't know when they were beginners (or possibly came in with more knowledge than beginners have). Another point (how many do I have?) There are more classifications of users than developer and non-developer, and they are all needed. XEmacs-guru-hood is far, far down my path, but I have some XEmacs-F now, and can help really new users get past some problems, and it is by reading questions and answers of others and searching out little nooks and crannies of XEmacs Truth to solve newer users' problems that I rise in XEmacs knowledge and get closer to that distant guru-hood. Helping new users inspires me to be better. That is why we need them--to make intermediate XEmacs users be better, so they become more than helpful problem solvers, and contribute to XEmacs directly. The last point I want to make is the number 10 on the list in your email should be to rewrite the documentation to reflect current, correct information. What is there should be preserved, but an updated copy should be published. Although I suspect that you will disagree, I think 2 new categories of documentation need to be added: - prose about how to do different tasks, because what we have is a "technical manual" and not task oriented, how to do things manual. such as -how to make a menu item for your lisp programs -how to change different parts of XEmacs -kbd macros -making new icons (wait till you see the extension to xpm mode) -printing in XEmacs: -there are 3 ways to print and they all do different things so some prose describing those ways -how to do it under windows (color vs no color, sideways, etc) -how to write and troubleshoot elisp code how features of the editor help. - short videos explaining the using of different parts of XEmacs. such as -5 minutes on the 3 methods of copy/pasting text and the 4 ways to do it. -5 minutes how to use dired (I can use that!) -5 minutes on how to use org mode -"how to use" any of the packages that exist (maybe enlist authors) I am suggesting a by-monthly sort of newsletter type thing posted to the website (that would be new--regular updates to the website (grin)). After a year of that, people would have quite a resource to go to to see new things to do and new packages to try out (and not bother developers with simple questions). I am suggesting a new section on the web site for hosting videos, if streaming is not possible (expensive), maybe just downloading them would be better? I know, I know, who is going to contribute those things? It *is* a bit of work. And it is not *coding* work that the people who get past the allow-remote-paths bug are more interested in. But it would help the project. Right now I have 4 elisp projects that I want to upload, and that is more important than getting a video thing going. But I am stuck on that too. I created an account, but when I try to upload an ssh key they will not take one I created by copy/pasting it in and when I browse to it instead of pasting, it does not take that ssh key either and says invalid key both times. So when I get past "something so small as the allow-remote-paths" problem, I will be working on learning some about ssh keys and what makes one created on my machine be declared invalid. Are there different kinds/levels? I mention this as the kind of thing that is tripping me up. I guess one final point that I am trying to make is that the things on your list that are holding people back (4 of them) are probably not the things that are holding me back. Sitting here in my living room or in my machine shop, writing code to work on my cnc programs, with no contact with other elispers save the beta mail list, the single thing that is holding me back is having to learn from the existing documentation. I may not be typical, I just don't think I am alone and I don't think it is a small problem. Hope my (temporary) discouragement of the moment isn't too gloomy. Steven Mitchell PS the clue that I got from -debug-paths was that my configure-exec-directory and exec-directory are a little different than I would expect it to be: nil "/usr/local/lib/XEmacs-21.5-b31/x86_64-unknown-linux/" Where did the unknown-linux come from? But I have no standard directories and list of what-gets-put-where, to compare my clue to. So have to work some more on it and study it out. ---snip--------------------------------------------------------------- symbol's value as variable is void: allow-remote-paths Stephen J. Turnbull stephen at xemacs.org Wed Jul 28 07:50:48 EDT 2010 Previous message: symbol's value as variable is void: allow-remote-paths Next message: symbol's value as variable is void: allow-remote-paths Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Andreas Röhler writes: Really? I really don't think so. We picked up two new potential developers in the last week. In any case, what's important to me is that it's not going to disappear from *my* screen any time soon, and therefore I'm going to work on what I need. If you think a course change is in order, submit patches and cooperate with requests from reviewers to improve them is the best thing to do. For the record, I believe that (1) people who are stopped by something as small as the allow-remote-paths bug or separate installation of XEmacs and the packages are extremely unlikely to become developers (2) ditto CUA keymap What's holding people back that's important: (1) We're a fork of a GNU project; politics makes GNU more attractive to a lot of people (and not a few in the other direction, but mostly to the extent it matters I think it works in GNU's favor). (2) We're not GPLv3 yet, and therefore most of our external packages and much internal code is behind GNU Emacs. I think the biggest costs are things like nxhtml, so we're not dead yet. (3) Emacs LISP is a crufty variant of a niche language. (4) Most elisp applications appeal to crypto-hacker types, rather than to ordinary users and developers. Lots of rough edges, not much flash. Much of the code is twisted and sucky. What we can do to attract new users likely to become developers (to some extent in order of importance): (1) release under GPLv3+, which will unblock packages and core code syncs. (2) Modernize elisp (Aidan's done a lot of Common LISP compatibility work; I would prefer a move toward Scheme, but since he's doing the work, I can only applaud). (3) Make XEmacs much more web-aware. Make URLs the standard input format for find-file for example (probably renamed to find-resource or retrieve-url or something like that). Get robust support for URL fetching (curl, neon, stuff like that) and editing (WebDAV). (4) More robust support for Unicode as such, and non-traditional characters in general (eg, spaces in file names). (5) GNU syncs, both in core and packages. (6) Large file support. (7) Better font support. (8) Improved ease of installation. (9) Exciting new features ... but that's for the new developers. :-) Personally, I intend to spend time on (1), (3), (4), and (7). (8) is way down the scale right now. Previous message: symbol's value as variable is void: allow-remote-paths Next message: symbol's value as variable is void: allow-remote-paths Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the XEmacs-Beta mailing list _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Looking into this again I realize I must have been very lost the last time I looked at it. The thing is this. When you launch a binary without any packages at all you get an unhelpful "Symbol's value as variable is void: allow-remote-path" message. I then thought erroneously that we had some simple support for download in the core and the first step was to see to that we don't barf on allow-remote-path being undefined and then make the core download work. This isn't the case. There is no core download. You need a few packages to get going. (I knew this but maybe I had a bad dream or something and forgot that ;-() The docs does describe what steps you need to take to bootstrap into a minimal set of packages for starting to use the package system. So the info is there. I haven't really checked that the instructions are good but they can be found. So what about possible basic improvements to the package system!? - Provide some better feed back to a user who starts using the package system without the basic packages installed. The Symbol's values as ... message isn't very helpful. However users who use installers on Windows or other distros will hopefully find that the basic packages are already provided or available to install through other means, eg the installer or the distros package manager. - Provide download capabilities in core such as use libcurl. This would possibly allow a bare binary to download even the basic packages. Ideas? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Thanks for a long reply. I think I need to take it piece by piece to digest it. There seems to be rally a lot to consider here. I feel partially lost. Different use cases. Different requirements. First part up for discussion. OK. We need to get the basic packages in somehow to bootstrap. Couldn't the bootstrap packages just be available for the package system? If user can install the binary why not install the bootstrap packages with it but only use it for the package system? (A lot like having curl in core for downloading the packages.) The normal case for bootstrapping would also be when there are not packages available!? If the distro or user himself has downloaded the full packages we need not bother about the bootstrapping. In that case we are talking more about what the package system should do when there is full tree already available. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

This is a little off the "Package system improvements" thread, but still about paths to lisp code. In Windows, XEmacs is installed under Program Files. That is not accessible over a network, because Windows doesn't want you to share your Program files over your own network. That complicates things when you want to update a lisp file to several computers over your network. So I made a directory which I could share over the network, and made a directory in Slackware to match, so I can update from either direction. Where should user-written lisp code be placed? Is that what "site-packages" is for? Does site refer to all users on a single system? Or does site refer to a site like a whole local network? Where an administrator would install packages and everybody use them? There is reference to third-party packages in the docs(or web page? I forget). Is there somebody out there who distributes code that way? Packages that are for XEmacs but are not submitted to the XEmacs project? Or am I misunderstanding what is meant? Getting back closer to topic: Stephen, I don't have the historical perspective that you and others do. I am trying to understand the cases that users would have previously installed packages that are installed in other places. What kind of packages would they have installed in other places? It this for people with multiple versions of XEmacs installed? To avoid having a second copy of each package on the hard drive? If so, the reality of the day is that we have 500 GB and 1 terabyte hard drives cheap and extra copies of packages might not be a problem as far as saving space goes. If i have a 21.4 install and it is encapsulated with it's own copy of packages all in a self contained folder setup, and 21.5 in a similar setup so they each do not depend on each others files, I would think that was desirable. Maybe that is wrong and developers have multiple versions done differently? I only have multiple versions installed on 1 Windows system, so maybe I don't understand how it is done in Linux. Maybe there are other historical reasons that still apply to this? Any idea how many users actually have packages installed in different places? (other than me, when I installed them in the wrong place (grin)) Steve Mitchell _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

This assumes the source is newer than the packages. Blindly installing the bootstrap packages from the source might be a bad idea. Maybe we need to limit the scope of what improvements we are trying to do? It seems like the general case of working perfect under all circumstances could be hard to tackle at least now. I can't see through all the twisty little maze of packages anyway! My original goal was to make the package system work so that a user could install the binary, from source or from an installer, and go on from that using what is built in[1] For mercurial or tar-ball-users it might be solved with an option to configure or a make target!? More useful is maybe to address the issue with when a user is on an existing installed system and wants to update or install new packages. This ought to be of benefit for many users. That use case might actually work out of the box. Building everything from sources has kept me away from that use case almost entirely. However when I just tried it it did fail. First obstacle. I didn't have ftp on my path. I fixed that but then getting the package list turned into an endless loop somewhere. I guess this would make most users give up on the idea of using the package system. I'll see if I can get past this point some how and see what other problems might occur. Footnotes: [1] I actually assumed there would be no previous packages installed in this scenario but its usefulness might be to limited!? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Is this supported at some level today? I fail to find where I want the packages installed so I assumed the package system would already have some logic to where to put them. I should really look at the code I think in order to understand this better. I know to little how it works now (maybe because the problems of getting it to work at all but I'm working on that.) Can you have the cake and eat it? I guess the package system then needs to install new downloaded packages in a new place where no user modified packages can exist. This way we won't overwrite the users modified packages. Now I though that xemacs-packages and mule-packages would be such a place where users should not modify the code. Installing a sumo tar ball would have the same disastrous effect!? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Regarding the overwriting of user-edited packages, first just the 2 we need to do, and then the rest. Add some intelligence to the installer, maybe by having some lisp code do the installing instead of a tar file. shell scripting might work as well(?) Something like this: ------- -First get info about what is already there -the path used in the XEmacs install for the package directory. -if either of the two files we are installing (efs, base) exist in that spot. -Check if they exist elsewhere. -look for filename -double check by looking inside that file for version/signature -Report what we find, -if these two packages are not found present to user where you plan to install -ask for -confirm? -user supplied path? -exit? -for each of the 2 packages (base and efs), if package is found -ask user overwrite? rename old packages and install new? exit? -Install 2 files -find the downloaded files uncompress and install them to the path -Report to user -what was installed -where we put it. Something like this might avoid the problems of overwriting a user-edited efs or xemacs-base, should that ever exist. ------- A separate problem is overwriting the rest of the packages if users have indeed edited other packages. Maybe the package manager itself could be modified so if replacing a package, either prompt to: -backup old package by renaming -overwrite old package -skip this package, go to next package if there is one selected to install ------- The above is not exact flow, just a general idea. Steve M. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Just throwing out an idea that is in between what has been suggested. Less automatic... Right now you install a tar.gz for source, (compile...) and then 2 tar.gz's are installed to bootstrap the package system. What if there was a 2 pronged approach: 1. put code in (a function that runs before current code that the menu points to starts running) to make the error message helpful, and to say " we looked in /<wherever> for <filenames> it looks like you do not have the files installed to start the pkg system, do these steps to install .... then give examples with the actual paths expected for installing on this system. (that they can download and copy and paste), and an option to manually change the paths that XEmacs looks in, for special cases. 2. Optionally, combine in a tar.gz both efs and xemacs-base and enough of an installer to search out the paths needed, and perform them, maybe showing what it found and allowing the user to change them manually before proceeding. the idea is to get meaningful error handling, and reporting details about the failure, then give directions for their system (with option to change). --------------------- I was trying to imagine the entirety of the use cases here. When I searched Google for the error, I find 1-2 cases about 2 years apart (that somebody had this error and went so far to report it) going back around 7-8 years. I don't have empirical data, but the people who get it seem to be: -nobody in windows -nobody who does the sumo option -nobody who installs from .rpm, etc. that include the package system. -somebody who installs from source. If those observations are anywhere close (I'm not sure how close they are) maybe the effort of working on the FFI and libcurl is more than the solution needs? Since most users (that we know of) seem to get it installed someway, maybe the above 1 or 2 steps might help people get past this. I would like the FFI from SXEmacs and libcurl, don't get get me wrong there, but maybe this would fit available manpower now? Just a suggestion. Think about it and please point out the problems you see. Steve Mitchell On 12/6/2011 1:34 AM, Mats Lidell wrote: _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: ffi-curl.el in SXEmacs is a whoping 350 lines ;) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats, A couple of suggestions: 1. improve the error message (probably what you were suggesting): Something like what file, part of which package, is being looked for, and in what places. example: Cannot find file xxx.xxx of package xxx in paths (list of places looked). Gives the guy with the error some things to look for: -a filename to search for in his system - package name the file is part of, so he knows which step went awry. -a place (or places) that it would be expected to be found. -gives something to google for, when stumped. 2. improve the documentation by adding a paragraph mentioning the error. Example: (from notes I wrote myself when solving this error last week) "One error that may come up at this step is the minibuffer may display: Symbol's value as variable is void: allow-remote-paths The most likely problem to cause this error is XEmacs is not finding the 2 packages (efs and xemacs-base) that we downloaded and installed in previous steps. Check first that the 2 packages were unpacked in the correct place. Second, check carefully the ./configure options that you selected before compiling the XEmacs source code. particularly the options having to do with paths. You may have to go back to the /usr/src/ directory and assemble a new ./configure command line, and start the install process over from that point, since the paths for your installation are set by running ./configure and are compiled into your XEmacs executable." Looking at those notes, the "unpacked in correct place" above should probably have the correct place listed *right there* to be thorough. Steve M. On 12/02/2011 07:24 PM, Mats Lidell wrote: Mats, when I got this same error, it was not when running the command xemacs, but after running xemacs, then choosing (from the menu) either: [Tools][Packages][Update Package Index] [Tools][Packages][List and Install] It may happen other times, but that was the only time I experienced it. I agree that *most* of the info is there, and it is pretty good, but (just my opinion) there are some spots that need wrinkles smoothed out. For just one example: on http://www.xemacs.org/Documentation/packageGuide.html under the heading Installing by Hand, it lists the following command: | gunzip -c ...../xemacs-base-1.27-pkg.tar.gz | tar xf - I could not get 5 dots in a row to work, thought they might have meant ../../ or ... ../ or ../../../ or other iterations. I tried to understand what was meant. I even (don't laugh) googled "...../" in desperation, and just for the record "...../" has no results (grin). Maybe they meant $prefix there or something. So I guessed what they meant and got it wrong the first couple times, installing the packages in the wrong place. I'd be embarrassed to admit that it took 3 evenings working at it to realize that I guessed at that step, and that my guess being wrong was the problem. I kept looking in other places for errors. There are other wrinkles too, that is just one example that stopped me. | _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Hi there, I’ve just done the work to a) merge the current SXEmacs FFI code into the xemacs-ffi repository, b) merge the current trunk code into that same repository and c) move the repository to bitbucket. It’s available as https://bitbucket.org/kehoea/xemacs-ffi . Best, Aidan -- ‘Iodine deficiency was endemic in parts of the UK until, through what has been described as “an unplanned and accidental public health triumph”, iodine was added to cattle feed to improve milk production in the 1930s.’ (EN Pearce, Lancet, June 2011) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Richard Cook writes: I've made the changes (actually, four places needed to be changed). If you want to work on the website, you need an account on alioth. Go to http://alioth.debian.org/ to request one. If you are not a Debian maintainer, your requested account name will automatically have "guest" appended to it. You may or may not want to take that into account (eg, I'm "unwelcome-guest"). Once you've done that, send xemacs-services(a)xemacs.org your account name, say you want website update privileges, and we'll set up privileges for you. See http://www.xemacs.org/About/Website.html for more information about the website update system. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

On Mon, 26 Jul 2010 21:00:54 -0700 Richard Cook <rcook(a)llnl.gov&gt; wrote: This is a common problem. I have the following in my .xemacs/init.el: (or (boundp 'allow-remote-paths) (setq allow-remote-paths nil)) Cheers, Sean _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta