Re: Full text search?

PA <petite.abeille <at> gmail.com>
2005-03-01 00:16:01 GMT

On Feb 28, 2005, at 21:20, Javier Guerra wrote:
> most people thought of something like this:
Yes, well... I contemplated using a straight table as well... but...
decided against it as this doesn't help much for partial match... you
still need to do a string.find() for that... or have a proper index
structure... which I was too lazy to implement :P
Another consideration for using the document id as keys is that it much
easier to update the index... just drop the entry for a document and
reindex its text content... using an inverted index is too much house
keeping for my humble needs.
Storing the text as a digest of sort slightly boost the string.find()
performance (less stuff to scan) and provide an implicit ranking as
more frequent tokens are found earlier in the digest.
All in all, kind of work ok for its simple purpose.
Cheers
--
PA, Onnay Equitursay
http://alt.textdrive.com/

Re: Application of indexing to all types

Gunnar Zötl <gz <at> tset.de>
2005-03-01 12:44:55 GMT

DR> I've been thinking, which isn't a good sign...
if you say so...
DR> I think it would be nice to extend the use of '.' and ':' to all types.
DR> I'd like to be able to do something like this:
I don't feel this would be such a great idea, from a consistency point
of view. Using the colon or dot notation on a table means that you
consider this individual table and its metatable(s) in order to resolve
the table lookup and thus the resulting operation. The lookup of the
required field occurs in the context of the _value_ in question, and
is thus dynamic.
Your proposal would lead to a second, very different meaning for the
colon, namely that the resolution of the table lookup would occur
someplace else. As strings and numbers are immutable values, it would
not make much sense to directly attach a metatable to such a value.
Also, you can not do table lookups on them. So you'd have some global
means to do the required lookup. But then the lookup does not take
place in the context of your value any more. Instead, it happens in
the static environment of the _operation_ in question. Of course, you
could use setfenv() to work around this, but this opens another can of
worms.
Thus, you'd end up with two meanings of the colon operator, that
differ in both semantics and binding. That's way too much differing
for me to support such a change.

Re: Some small requests for the next release

David Jones <drj <at> pobox.com>
2005-03-01 12:54:40 GMT

On Feb 28, 2005, at 17:09, Mark Hamburg wrote:
> on 2/28/05 8:32 AM, David Jones at drj <at> pobox.com wrote:
>
>> Show me some code that might use math.nan. if x == math.nan ? I
>> don't
>> think so.
>
> x = 0
> for index = 1, 100 do
> x = x + ( t[ index ] or math.nan )
> end
>
> Any missing indices will result in a sum of NaN.
That seems reasonable; I'm convinced that on machines that support NaN
there might be good uses for math.nan (and the case for math.isnan and
math.isinf is even clearer).
So, supposing that one adds math.nan, what value should math.nan have
on machines not supporting NaN? 0, nil, false?
David Jones

How to call a Lua object method fom a function in C?

Michael Cumming <Mike.C <at> Promixis.com>
2005-03-01 14:05:45 GMT

Follow question to below...
How does one pass an object method to C so the C can call the object method back?
Ie.
Lobject = { callback = function (self...) .... end}
PassObjectCallbacktoC (Lobject.callback) -- note Lobject:callback cannot be passed.
Adam, Rici,
Thank you for the replys... so a quick guess at the code would be...
if (lua_isfunction (L,1)) // we have a function
luacallbackfunction = luaL_ref(L, LUA_REGISTRYINDEX);
When I want to use the function I can do
lua_rawgeti(L, LUA_REGISTRYINDEX, luacallbackfunction);
lua_pushxxx for the params
lua_pcall (xxx)
Thanks again,
Mike

Re: Problems declaring objects inside package

Mark Swinson <mswinson <at> btinternet.com>
2005-03-01 17:52:28 GMT

>
> OOP-like functions, using the ':' syntax aren't local nor global, they're
> put
> into the 'object' table. just remove the 'local' keyword
>
taking the local declarations away works, but the Account and SpecialAccount
objects
are now visible in the global env table _G which defeats the purpose of
declaring it in
a package. How can I do it while keeping those objects hidden from outside
users.
Mark

Re: Problems declaring objects inside package

> How can I do it while keeping those objects hidden from
> outside users.
>
Just remove the 'local' keyword for the functions and keep it before
'Account = {}'
--------------------------
-- Leave 'local' here
local SpecialAccount =
{
limit = 1000,
new = Account.new
};
-- But remove from here
function SpecialAccount:getLimit()
return self.limit or 0;
end
--------------------------
--rb

Re: Application of indexing to all types

Doug Rogers <rogers <at> innocon.com>
2005-03-01 18:26:22 GMT

Gunnar Zötl wrote:
>As strings and numbers are immutable values, it would
>not make much sense to directly attach a metatable to such a value.
>
[I do not follow the reasoning here - why immutability plays a role in
whether or not a metatable makes sense. But that's really not at issue
to what I've proposed.]
>... But then the lookup does not take place in the context of your value any more. ... Thus, you'd end up with
two meanings of the colon operator, that differ in both semantics and binding.
>
Thanks for the comments, Gunnar. Indeed, thanks to all who have
commented on this thread.
I wrote a longer version of this, but I've decided to state it briefly
(it's long enough):
(1) My original proposal
http://lua-users.org/lists/lua-l/2005-02/msg00666.html is more complex
than necessary.
(2) My simpler proposal is slightly more than Adrian Sietsma indicated:
x:func(...) ==> (x.func or _G[type(x)].func or func)(x, ...)
(3) This does not require metatables for the other types.