gmane.emacs.sxemacs.devel

Re: Can't build sxemacs

rh — 2013-05-17T19:05:07

On Thu, 16 May 2013 12:55:13 -0400
Nelson José Dos Santos Ferreira <njsf-46pdNH7qWAZAfugRpC6u6w< at >public.gmane.org> wrote:


I will try to do this if I can. I have built one now that doesn't spin.
I just added more options to ./configure.

I built without experimental features and without openssl. Not sure
what/where poll.h gets pulled in.

Re: Can't build sxemacs

Nelson José Dos Santos Ferreira — 2013-05-16T16:55:13

Could you rerun it with -i and also include /proc/<pid>/maps so we can have a better idea of the region of the spin ?

On May 15, 2013, at 11:54 , rh <richard_hubbe11< at >lavabit.com> wrote:

Re: Can't build sxemacs

rh — 2013-05-15T15:54:59

On Wed, 15 May 2013 08:43:03 -0700
rh <richard_hubbe11-N9AOi2cAC9ZBDgjK7y7TUQ< at >public.gmane.org> wrote:


This is what strace tells me, it's spinning tightly here:

poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
recvfrom(6, 0x29080e4, 4096, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

git and stable show this behavior and here are the build flags:

./configure --with-modules=nodbus,nocl,noase --with-mail-locking=no --with-included-ltdl --with-mule=no --enable-ltdl-install --with-clash-detection=no --with-debug=no --with-ipv6-cname=no

Re: Can't build sxemacs

rh — 2013-05-15T15:43:03

On Mon, 13 May 2013 10:19:47 -0700
rh <richard_hubbe11-N9AOi2cAC9ZBDgjK7y7TUQ< at >public.gmane.org> wrote:


I was able to build git and stable. But both are using 10% cpu
while standing still. I'll try to strace it and see what's going.

Can't build sxemacs

rh — 2013-05-13T17:19:47

Hello,

Have not been able to build sxemacs to try it out. I have newer
software because I needed some recent code.  X, mesa, etc.

Some facts... 
I tried a newer kernel but have to stick with 3.8.12 since it's working.
I tried building the stable version too.
conftest seg faults (may be expected??)

I found a strange link in sxemacs:
/sxemacs/.sxemacs.source.tree -> ./

and then make fails with
No such file or  directory
/sxemacs/.sxemacs.source.tree/modules/modules
sxemacs exiting
.
*** auto.stamp Error 255
all-recursive Error 1

uname -m = x86_64
uname -r = 3.8.12
uname -s = Linux

configure:11485: checking for autoconf version
configure:11487: result: autoconf (GNU Autoconf) 2.69
configure:11508: checking for autoheader version
configure:11510: result: autoheader (GNU Autoconf) 2.69
configure:11531: checking for aclocal version
configure:11533: result: aclocal (GNU automake) 1.11.5
configure:11554: checking for automake version
configure:11556: result: automake (GNU automake) 1.11.5
configure:11577: chec

[Bug 159] #'curl:download to a buffer instead of a file crashesSXEmacs

2013-04-29T09:09:45

http://issues.sxemacs.org/show_bug.cgi?id=159

--- Comment #4 from Zajcev Evgeny <zevlg< at >yandex.ru> ---
I'll take a look at May holidays

[Bug 159] #'curl:download to a buffer instead of a file crashesSXEmacs

2013-04-27T05:12:44

http://issues.sxemacs.org/show_bug.cgi?id=159

--- Comment #3 from Steve Youngs <steve< at >sxemacs.org> ---
Evgeny, can you give me an idea of how long you think you'll need to wrap this
one up? (I'm waiting on its resolution for some stuff that I'm doing)

[Bug 159] #'curl:download to a buffer instead of a file crashesSXEmacs

2013-04-17T23:54:17

http://issues.sxemacs.org/show_bug.cgi?id=159

Steve Youngs <steve< at >sxemacs.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from Steve Youngs <steve< at >sxemacs.org> ---
(In reply to Zajcev Evgeny from comment #1)

That's good news, at least it wasn't just me. :-)  Do you have a handle on it,
mate?  Let me know if I can do anything to help.


Well, at least we know it does work somewhere.

[Bug 159] #'curl:download to a buffer instead of a file crashesSXEmacs

2013-04-17T10:27:13

http://issues.sxemacs.org/show_bug.cgi?id=159

--- Comment #1 from Zajcev Evgeny <zevlg< at >yandex.ru> ---
Reproducable under Linux and MacOS

Can't reproduce under FreeBSD

[Bug 159] New: #'curl:download to a buffer instead of a file crashesSXEmacs

2013-04-17T01:05:42

http://issues.sxemacs.org/show_bug.cgi?id=159

            Bug ID: 159
           Summary: #'curl:download to a buffer instead of a file crashes
                    SXEmacs
    Classification: Unclassified
           Product: SXEmacs
           Version: 22.1.15
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Core Lisp
          Assignee: zevlg< at >yandex.ru
          Reporter: steve< at >sxemacs.org
        QA Contact: sxemacs-devel< at >sxemacs.org

Created attachment 152
  --> http://issues.sxemacs.org/attachment.cgi?id=152&action=edit
C backtrace

In a vanilla instance I tried the following in scratch buffer...


(require 'ffi-curl)

(with-temp-buffer
  (curl:download
"http://downloads.sxemacs.org/xemacs-pkgs/packages/package-index.LATEST.gpg"
                 (current-buffer)
                 :nobody t
                 :header t))


I also tried...

(curl:download
"http://downloads.sxemacs.org/xemacs-pkgs/packages/package-in

Re: problems with first time building package index

Steve Youngs — 2013-04-11T23:35:10

  > I set the archive, stack backtrace on error, and re-ran the pui-bootstrap
  > and here was the results

  > Invalid operation: "curl:easy-perform error", "FTP could not RETR file"

This is an error coming back from libcurl.  It's not an error from
SXEmacs, SXEmacs is just relaying the message. :-)

It is possibly a firewall/iptables issue.

Re: problems with first time building package index

kevinbanjo — 2013-04-11T16:48:10

I set the archive, stack backtrace on error, and re-ran the pui-bootstrap
and here was the results

Invalid operation: "curl:easy-perform error", "FTP could not RETR file"

  # bind (standard-output stack-trace-on-signal debug-on-signal
stack-trace-on-error debug-on-error)
  signal(invalid-operation ("curl:easy-perform error" "FTP could not RETR
file"))
  # bind (args datum)
  cerror(invalid-operation "curl:easy-perform error" "FTP could not RETR
file")
  apply(cerror invalid-operation ("curl:easy-perform error" "FTP could not
RETR file"))
  # bind (args datum)
  error(invalid-operation "curl:easy-perform error" "FTP could not RETR
file")
  # bind (err ctx)
  curl:easy-perform(#<ffiobject type=pointer size=4 fotype=0
foptr=0xa009c40>)
  # (unwind-protect ...)
  # bind (fs bufferp ctx options file-or-buffer url)
  curl:download("
ftp://mirrors.ibiblio.org/pub/mirrors/xemacs/packages/package-index.LATEST.gpg"
"/home/fish/.sxemacs/package-index.LATEST.gpg")
  # bind (efs-pkg xemacs-base-pkg index dldir url dir

Re: tramp-dropbox

Michael Albinus — 2013-04-11T09:03:13


Yep, this shall be configrable. When a dropbox daemon is running, Emacs
doesn't need to push/pull.


Not only. There might be people who do not install a dropbox client, for
several reasons. The user doesn't like closed software, the machine is a
server which doesn't allow dropbox clients, the machine is a simple one
like a NAS which is not supported by dropbox, you name it ...

What if you want to access two different dropbox accounts in parallel,
for example in order to compare files? Don't know, whether ordinary
dropbox daemons support this.


They are the "remote counterparts" to `call-process' and
`start-process'. If `default-directory' is a local path, they call
`call-process' or `start-process', respectively. If it is a remote
directory, they work on the remote host. Very useful, I need it every
single day. 

Many packages support this meanwhile. Integration is easy, you just need
to replace the respective calls.

My preferred use case is "M-x find-grep-dired" on a remote directory ...


Yes :-)


M

Re: tramp-dropbox

Steve Youngs — 2013-04-11T01:04:32

  >> > Steve Youngs <steve< at >sxemacs.org> writes:

  >> >> o A Dropbox client.

  > The basic actions are clear: implement the file name handler functions
  > as for every other protocol, as much as possible. Something like
  > file-attributes, copy-file, write-region and friends.

You would only ever be working on local files, so none of this would be
needed.  All an emacs dropbox client would need to do is transfer to/from
the server, and then _only_ if there was no native dropbox daemon
running.

The emacs client would need two modes of operation, one where there is a
native daemon available, and one where there isn't.  In the case of the
former (native daemon available) the client should get everything it
needs from the daemon (which wouldn't be much).  All communication with
the dropbox server would be handled by the daemon.

Actually, now that I think about it, an Emacs Dropbox client should be
nothing more than a frontend to the native daemon running on localhost.
So forget what I said about two modes

Re: problems with first time building package index

Steve Youngs — 2013-04-10T00:35:09

  > aarg, following the info file, I tried the require ffi-curl and it
  > confirmed it was there. Then I set-package-get-remote to the first site in
  > the list and I did the pui-bootstrap and it worked for a bit and came back
  > with some kind of download error (didn't write it down) so I changed to the
  > ibiblio site and it said it couldn't ftp and now I'm trying to use the
  > xemacs.org site and update index and it says allow-remote-paths is void and
  > its stuck at that message no matter what path I set.

Yeah, the packaging tools (in both SXEmacs and XEmacs) really do not
handle this situation at all well (trying to use more than one site in
the one session).  It is really bad and I will see what I can do to fix
or improve it.

How far did the bootstrap get?  Do you know if the EFS and xemacs-base
packages were installed?  It's a pity you didn't grab that error you
got.

`allow-remote-paths' comes from EFS so perhaps you got past the actual
bootstrapping and you've gotten into trouble because of

problems with first time building package index

kevinbanjo — 2013-04-09T16:19:35

aarg, following the info file, I tried the require ffi-curl and it
confirmed it was there. Then I set-package-get-remote to the first site in
the list and I did the pui-bootstrap and it worked for a bit and came back
with some kind of download error (didn't write it down) so I changed to the
ibiblio site and it said it couldn't ftp and now I'm trying to use the
xemacs.org site and update index and it says allow-remote-paths is void and
its stuck at that message no matter what path I set.

I have this curl: net-misc/curl-7.29.0-r1

https://pastebin.sabayon.org/pastie/12435

anybody have a clue what I'm doing wrong?

or how I restart the process?

I mean, so if this thing did have some kind of network error with the first
package repository, why would it not recover gracefully rather than getting
stuck in void variable land? I even renamed my
`.xemacs/package-index.LATEST.gpg (the only thing I could find in my home
directory that looked like it *might* be what was built) and it still
errors out.

Also, can't I

Re: XEmacs has applied for GSoC

Steve Youngs — 2013-04-04T21:47:03

  > Steve Youngs <steve< at >sxemacs.org> writes:
  > [..]
  >> My ideas:

[...]

  > What about implementing interface to gobject introspection using
  > SXEmacsen ffi.  It would provide us extremely powerful tool to
  > interfacing with all the sweet and bitter of gnome stuff

All well and good, mate, except XEmacs doesn't have FFI and we're
talking about XEmacs here.

A number of years ago I went to all the trouble of porting our FFI to
XEmacs 21.5.  Had it all working.  Jumped up and down yelling "hey get
your FFI here!!!".  And... I think they just ignored it.

I tried.

I've since lost that XEmacs workspace.  Don't think I even have
mercurial installed anymore.

So, a better project idea for them would be to port our FFI. :-)

Re: XEmacs has applied for GSoC

Zajcev Evgeny — 2013-04-04T11:28:37

[..]

What about implementing interface to gobject introspection using
SXEmacsen ffi.  It would provide us extremely powerful tool to
interfacing with all the sweet and bitter of gnome stuff

[..]

tramp-dropbox (was: XEmacs has applied for GSoC)

Michael Albinus — 2013-04-04T06:56:51

[Cc to tramp-devel, for broader discussion]

Steve Youngs <steve< at >sxemacs.org> writes:


I've been there, of course.

The basic actions are clear: implement the file name handler functions
as for every other protocol, as much as possible. Something like
file-attributes, copy-file, write-region and friends. Other functions
cannot be implemented for the dropbox protocol, like process-file and
start-file-process; but those functions are not used in (S)XEmacs
anyway.

The interesting decisions are around synchronization: Should all saved
files be pushed to the server immediately? Should the server be checked
for file changes before a local copy is opened? Do we need local backup
files, or are the revision on the dropbox server sufficient? Shall we
make it configurable, which files to be synced (for example, exclude
local backup files)? Shall we support access to file revisions, via a
new package vc-dropbox? And so on ...

But so what, I shall be able to make my own decisions. Just a kick into
my ass would be help

Re: XEmacs has applied for GSoC

2013-04-03T23:43:46

 It's stands for low level virtual machine, but the neat feature of it is that there is a whole set of tools that then allow you to do just in time compile and optimization.

 
--
Sent from my mobile device. Please forgive the terseness, misspellings and other mistakes.
 


On 4/3/13 19:33 Steve Youngs wrote:

* Nelson Ferreira <nelson.ferreira< at >ieee.org> writes:


[ XE GSoC project ideas ]




OK, so I can sorta sound like I know what I'm talking about when I give
this to the XE people, what is "LLVM"?

Re: XEmacs has applied for GSoC

Steve Youngs — 2013-04-03T23:33:15

[ XE GSoC project ideas ]

  > I think a very interesting, and meaty one, would be for LLVM compiled
  > elisp, instead of bytecode.

OK, so I can sorta sound like I know what I'm talking about when I give
this to the XE people, what is "LLVM"?