Res: [Sputnik-list] New commit of Sputnik with Subversion

[Sérgio Medeiros]

Hi!

I made some tests  and I think one alternative, instead of use LD_LIBRARY_PATH, is to
compile LuaSVN using "-Wl,R/path", like this:

gcc -L /home/sergio/foo/sputnik/lib/  -Wl,-R/home/sergio/foo/sputnik/lib/  -O -shared -fpic   -o luasvn.so luasvn.o -lsvn_client-1 -lsvn_wc-1 -lsvn_ra-1 -lsvn_delta-1 -lsvn_diff-1 -lsvn_subr-1 -laprutil-1 -lexpat -lapr-1 -luuid -lrt -lcrypt -lpthread -ldl -lz

The problem is, if you move the directory where the libraries reside, you need to compile LuaSVN again, unless you compile LuaSVN using a relative path, like "../../lib", and move the whole block of files together. Another problem, I did not test this using other systems, like BSD.

This seems a better solution? It is more according that URL you sent us talking about LD_LIBRARY_PATH.

About, "get_object_history", if you do not return the timestamp, how are you planning to get it? Using a function that returns a given property of the revision?

Sérgio


----- Mensagem original ----
De: Yuri Takhteyev <yuri at sims.berkeley.edu>
Para: Sérgio Medeiros <tampo_8 at yahoo.com>
Cc: Sputnik <sputnik-list at lists.luaforge.net>
Enviadas: Sábado, 23 de Junho de 2007 22:14:58
Assunto: Re: [Sputnik-list] New commit of Sputnik with Subversion

First, after tweaking the sequence of commands a bit, I did manage to
build luasvn from scratch and to run it.  See
http://www.freewisdom.org/projects/sputnik/Building_LuaSVN

The bad news, however, is that when a module is built this way,
LD_LIBRARY_PATH must be set not only when it's being built but also
later whenever it is being used.  I imagine that xavante runs with
whatever environment variables are set at the command line before it
is started, but is typically configured to run with whatever variables
it wants to run.  Maybe there is a way to set LD_LIBRARY_PATH from Lua
before requiring luasvn - I am not sure.  Though, I seem to see that
people out there on the Internets are saying that LD_LIBRARY_PATH is a
dirty hack anyway.  (E.g.,
http://linuxmafia.com/faq/Admin/ld-lib-path.html)  So, maybe instead
of figuring out how to set environment variables in Kepler we should
look into what we should do to not have to set them.

> Once you have suggested the "get_object_history" should return two things for each file: the
> ID of the file and the last time it was modified.

I still think so to some extent.  Conceptually, there are two separate
things: an revision ID, which could be anything, an, and a timestamp,
that needs to be in a particular format.  My implementation for
wikifilestorage used timestamps as IDs and mixed them everywhere, but
this is a mistake to be fixed, rather than emulated in all future
storage modules.

What I am not 100% sure about is whether get_object_history should
really be returning timestamps at all.  Part of me thinks it would be
cleaner if it just returned IDs.  After all, if we return timestamps,
why not also return username and other metadata.  So, it starts
smacking of a wikifilestorage-specific optimization.

> I tried to do this change once, it seemed to work. I don't know if you are still thinking this way, or
> if you think is better to use the config_table (I did not think about this yet).

The config table is a completely different story.  I am suggesting
that one would connect to a storage module using
`module_name.open(config)` where config is the table we get after
processing the config file.  This way, the module can pick whatever it
wants from the config file to initialize itself.  E.g. wikifilestorage
could use config.WIKI_DATA_DIR, sqlite storage would use
config.SQLITE_FILE_NAME, and storage systems based on other databases
could use DB_HOST_NAME, DB_USER_NAME, DB_PASSWORD, etc.  The point is
that Sputnik wouldn't need to know whether a storage module needs 1
config variable, 2 or 75.

Alternatively, we could use a single table-valued config variable for
that, which would be cleaner but probably more confusing to new users:

STORAGE = {
   module = "wikifilestorage",
   dir = "/home/yuri/sputnik/data/"
}

or

STORAGE = {
    module = "wikidbstorage",
    db = "mysql",
    host_name = "localhost",
    user_name = "test",
    password="apples"
}

  - yuri

-- 
Yuri Takhteyev
UC Berkeley School of Information
http://www.freewisdom.org/





       
____________________________________________________________________________________
Novo Yahoo! Cadê? - Experimente uma nova busca.
http://yahoo.com.br/oqueeuganhocomisso