On 20 October 2010 00:03,
<lua-l-request@lists.lua.org> wrote:
Send lua-l mailing list submissions to
lua-l@lists.lua.org
To subscribe or unsubscribe via the World Wide Web, visit
http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/lua-l-lists.lua.org
or, via email, send a message with subject or body 'help' to
lua-l-request@lists.lua.org
You can reach the person managing the list at
lua-l-owner@lists.lua.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of lua-l digest..."
Today's Topics:
1. Re: Userdata finalization order (Francesco Abbate)
2. Re: Non local variables not becoming global? (Scott Vokes)
3. Re: Userdata finalization order (Petite Abeille)
4. Re: Non local variables not becoming global? (Saptarshi Guha)
5. Re: Userdata finalization order (Wesley Smith)
6. Re: luaO_str2d, strtod and hexadecimal numbers under IRIX
(Rainer M. Canavan)
7. Re: Userdata finalization order (jgiors@threeeyessoftware.com)
8. Re: Load large amount of data fast (Alexander Gladysh)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Oct 2010 22:36:14 +0200
From: Francesco Abbate <francesco.bbt@gmail.com>
Subject: Re: Userdata finalization order
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID:
<AANLkTimSfbc=DH13M75syCwepTdPHpbo8G6HqHKX87-k@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/10/19 Wesley Smith <wesley.hoke@gmail.com>:
> It's extremely hard to follow your weak table code, which is maybe why
> you didn't post it before. I still don't wee where your weak table
> is. There's no __mode field set in what you post, and I imagine from
> this code that the rest of your code is pretty hairy. If you could
> draw a diagram showing dependencies, it might help, but it's my
> opinion that you really need to simplify this stuff.
Well, Wesley, I don't see the point. This code about weak table is not
really interesting and it is evident that I'm creating the weak table
elsewhere. I'm not sure that your comments about my code which is
hairy are really justified.
>
> I'm not sure why you have lines and transforms represented as objects
> in the first place, but assuming that's a desirable feature, you are
> going to either have to have a reference counting mechanism or a clear
> line of ownership modeled in lua using the environment table of a
> userdata. For this last case, you could have Plot act as a factory
> for Lines and Transforms. Plot owns those objects. When they're
> pushed in to Lua, their userdata is linked to the Plot environment
> table, preventing them from being collected if no longer referenced in
> a script. When Plot is collected the Line and Transform userdata do
> not free the underlying C++ structures because it's Plot's job to do
> that.
Please look at this video to see what my application can do right now
and may be you will be more understanding :-)
http://dl.dropbox.com/u/1156356/out.ogv
Please note that the 3D graphics is much more smooth in reality then
what is shown in the video :-)
Of course I accept the criticisms and I'm absolutely sure that in many
area the design could be simplified by changing some strategic choice.
I'm just struggling to get something simple and elegant to manage the
graphical elements and what I'm seeing is that the only acceptable
answer is reference counting.
--
Francesco
------------------------------
Message: 2
Date: Tue, 19 Oct 2010 16:38:55 -0400
From: Scott Vokes <vokes.s@gmail.com>
Subject: Re: Non local variables not becoming global?
To: saptarshi.guha@gmail.com, Lua mailing list <lua-l@lists.lua.org>
Message-ID:
<AANLkTimhH18_gFpUocdFtCzz6ptj5+-VroHG=JJ+7fJp@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Oct 19, 2010 at 1:23 AM, Saptarshi Guha
<saptarshi.guha@gmail.com> wrote:
> Is there anyway to force chunks to create variable in the current context rather
> than in global when local is not specified?
That's what local is *for*.
If you're worried about accidentally making global variables, look
at strict.lua in the standard Lua distribution - it uses the global
table's metatable to intercept any attempts to set global variables
that haven't already been declared. While having variables be "global
by default" seems dangerous, in practice any problems it could cause
are easily prevented.
Scott
------------------------------
Message: 3
Date: Tue, 19 Oct 2010 22:40:28 +0200
From: Petite Abeille <petite_abeille@mac.com>
Subject: Re: Userdata finalization order
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID: <95E44E58-CE1E-4BAB-AF40-0CB961AF8C1C@mac.com">95E44E58-CE1E-4BAB-AF40-0CB961AF8C1C@mac.com>
Content-Type: text/plain; charset=us-ascii
On Oct 19, 2010, at 10:36 PM, Francesco Abbate wrote:
> Please look at this video to see what my application can do right now
> and may be you will be more understanding :-)
>
> http://dl.dropbox.com/u/1156356/out.ogv
>
> Please note that the 3D graphics is much more smooth in reality then
> what is shown in the video :-)
Nice demo. Thanks for sharing :)
------------------------------
Message: 4
Date: Tue, 19 Oct 2010 13:51:30 -0700
From: Saptarshi Guha <saptarshi.guha@gmail.com>
Subject: Re: Non local variables not becoming global?
To: Scott Vokes <vokes.s@gmail.com>
Cc: Lua mailing list <lua-l@lists.lua.org>
Message-ID:
<AANLkTimxaYcJ9H-Lov5yd1iROSnuN8=-1vEctiocKPfc@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Thanks all.
On Tue, Oct 19, 2010 at 1:38 PM, Scott Vokes <vokes.s@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 1:23 AM, Saptarshi Guha
> <saptarshi.guha@gmail.com> wrote:
>> Is there anyway to force chunks to create variable in the current context rather
>> than in global when local is not specified?
> Â That's what local is *for*.
>
> Â If you're worried about accidentally making global variables, look
> at strict.lua in the standard Lua distribution - it uses the global
> table's metatable to intercept any attempts to set global variables
> that haven't already been declared. While having variables be "global
> by default" seems dangerous, in practice any problems it could cause
> are easily prevented.
>
> Scott
>
------------------------------
Message: 5
Date: Tue, 19 Oct 2010 14:02:13 -0700
From: Wesley Smith <wesley.hoke@gmail.com>
Subject: Re: Userdata finalization order
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID:
<AANLkTimvf4_2nh=r=9ixYtRpvXyNfnTSW5At1OHMRXLZ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> Well, Wesley, I don't see the point. This code about weak table is not
> really interesting and it is evident that I'm creating the weak table
> elsewhere. I'm not sure that your comments about my code which is
> hairy are really justified.
>
Sorry. I wasn't trying to disparage your code, but just point out
that the code you posted doesn't show how lines related to plots in
terms of using Lua for reference counting without a lot of extra
information.
> Of course I accept the criticisms and I'm absolutely sure that in many
> area the design could be simplified by changing some strategic choice.
>
> I'm just struggling to get something simple and elegant to manage the
> graphical elements and what I'm seeing is that the only acceptable
> answer is reference counting.
>
I think the problem you're running in to as I said before is that
there is no clear line of ownership in the C++ classes, so the user
has to manage it. If that's the case, you can make an abstraction
layer in C++ that does this without involving Lua (this is the idea of
the factory in my previous email), implement something like reference
counting that that the userdata knows when it's safe to free itself,
or push the responsibility on to the Lua scripter, which is probably
not so nice since the user will have to manually untangle objets that
depend on each other.
wes
------------------------------
Message: 6
Date: Tue, 19 Oct 2010 23:16:57 +0200 (CEST)
From: "Rainer M. Canavan" <lua@canavan.de>
Subject: Re: luaO_str2d, strtod and hexadecimal numbers under IRIX
To: lua-l@lists.lua.org
Message-ID: <201010192116.o9JLGvOA002246@tezro.nonet>
Content-Type: text/plain
> From: Roberto Ierusalimschy <roberto@inf.puc-rio.br>
> Could you send only a diff of your changes to luaO_str2d (without debug
> prints)?
Enclosed below. It's certainly not an optimal solution and
should probably ifdef'ed out if performance is a concern.
A more complete solution would probably be to use the gnulib
implementation if the system version is buggy.
> From: Mike Pall <mikelu-1010@mike.de>
[...]
> Well, it's a violation of ANSI C only present in IRIX. And IRIX is
Apparently, AIX has (had?) it as well. 7.1 was released in September.
http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/22410
Considering the widespread, but usually more subtle bugs in
strtod, I'd not be surprised if other implementations had
similar problems.
> for all practical purposes 'dead'. IRIX 6.5 is from 1998, the last
> minor update 6.5.30 is from 2006 and hardware production has been
> stopped in 2006, too.
It's still supported, at least until December 2013.
regards,
rainer
--- lobject.c Sun Oct 17 21:21:14 CEST 2010
+++ ../../../lua-5.1.4/src/lobject.c Tue Oct 19 22:55:08 CEST 2010
@@ -89,12 +89,15 @@
int luaO_str2d (const char *s, lua_Number *result) {
char *endptr;
+
*result = lua_str2number(s, &endptr);
- if (endptr == s) return 0; /* conversion failed */
- if (*endptr == 'x' || *endptr == 'X') /* maybe an hexadecimal constant? */
-{ printf('hex!!! %s\n', endptr);
+ *result = strtod(s, &endptr);
+ if ((*s == '0') &&
+ (*(s+1) == 'x' || *(s+1) == 'X')) /* maybe a hexadecimal constant? */
+ {
*result = cast_num(strtoul(s, &endptr, 16));
-}
+ }
+ if (endptr == s) return 0; /* conversion failed */
if (*endptr == '\0') return 1; /* most common case */
while (isspace(cast(unsigned char, *endptr))) endptr++;
if (*endptr != '\0') return 0; /* invalid trailing characters? */
------------------------------
Message: 7
Date: Tue, 19 Oct 2010 14:19:10 -0700
From: <jgiors@threeeyessoftware.com>
Subject: Re: Userdata finalization order
To: lua-l@lists.lua.org
Message-ID:
<20101019141910.1f05e918426bb2e3d00030bbd04c88bd.8f8fd0a6b2.wbe@email06.secureserver.net">20101019141910.1f05e918426bb2e3d00030bbd04c88bd.8f8fd0a6b2.wbe@email06.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> ------------------------------
>
> Message: 3
> Date: Tue, 19 Oct 2010 17:06:08 +0200
> From: Francesco Abbate <francesco.bbt@gmail.com>
> Subject: Re: Userdata finalization order
> To: Lua mailing list <lua-l@lists.lua.org>
> Message-ID:
> <AANLkTimGqg11tvndESaBwzRESOqm9qotezKdRx_RHWfA@mail.gmail.com">AANLkTimGqg11tvndESaBwzRESOqm9qotezKdRx_RHWfA@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2010/10/19 <jgiors@threeeyessoftware.com>:
> > By your description, it sounds like an "owner" pattern -- plot A owns
> > line B, and on the C++ side, B is deleted when A destructs, i.e. B would
> > not be deleted independently from A if you were writing the app in C++.
> >
> > So, couldn't this problem be avoided by *not* having a finalizer for
> > line B?
> >
> > i.e. the only way line B would be C++ destructed is when plot A's
> > destructor is called and it deletes all contained elements (one of which
> > is line B).
> >
> > This would work on final cleanup and also if plot A were dereferenced
> > prior to final cleanup. You would still need to ensure no Lua code
> > dereferences line B independent of plot A.
>
> Well, this is quite not true because the object B can exists also
> indipendently from object A. For example you can write in GSL shell
> the following code:
>
> ln = fxline(sin, 0, 2*pi) -- create a "line" object
> p1 = plot('Test plot #1') -- create a "plot"
> p1:addline(ln)
> p2 = plot('Test plot #1')
> p2:addline(ln)
>
> As you can see the object "ln" can exists indipendently from any plot
> but it can also be attached to one or many plot (this is the zero,
> one, infinity principle, I guess :-) )
>
> So neither "p1" or "p2" owns the object line. The object line exists on its own.
>
> Note that this pattern is perferctly normal for Lua and if all the
> objects were native Lua objects there would be absolutely no problem.
> The GC knows about the existing objects and know that p1 refers to
> "ln" so that it will never deallocate "ln" as far as either p1 or p2
> are alive.
>
> The troubles came when ln, p1, p2 and C++ objects since, as I'm trying
> to explain, Lua does not have any satisfying mechanism to ensure
> proper management of the reference among C++ objects. The only model
> that works is to create a reference counted objects, then create the
> userdata which is just as a boxed C++ pointer and define the Lua
> finalizer function so that it just "unref" the object. In this way the
> object will be freed only when nobody make reference to it and
> everyone will be happy.
>
> --
> Francesco
I thought the original problem was that, upon finalization, the plot
would attempt to access an element, but the element could have already
been finalized. Why does the plot access elements on finalization? Is
that in order to delete the elements?
If I'm misunderstanding, then the rest is a moot point, but anyway:
If the access is in order to delete elements, that is incorrect (even if
the app were entirely C++), e.g. an element could belong to two plots
and be deleted twice.
Would the following work? Elements have a finalizer (just like before),
but the finalizer for the plot does *not* attempt to delete referenced
elements (nor attempt to do anything else with referenced elements).
John Giors
Independent Programmer
Three Eyes Software
jgiors@ThreeEyesSoftware.com
http://ThreeEyesSoftware.com
------------------------------
Message: 8
Date: Wed, 20 Oct 2010 02:02:29 +0400
From: Alexander Gladysh <agladysh@gmail.com>
Subject: Re: Load large amount of data fast
To: Lua mailing list <lua-l@lists.lua.org>
Message-ID:
<AANLkTinmg5X_zf8mTxHNm3ffwBQnY8dkFD05BHVWFgTc@mail.gmail.com">AANLkTinmg5X_zf8mTxHNm3ffwBQnY8dkFD05BHVWFgTc@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sun, Oct 17, 2010 at 06:10, Alexander Gladysh <agladysh@gmail.com> wrote:
> On Sun, Oct 17, 2010 at 05:56, Alexander Gladysh <agladysh@gmail.com> wrote:
>> Jerome, Petite, list,
>>>> I'm trying to load that 3M entries in to Lua table in memory faster
>>>> than I do it now.
>> Thanks for answers.
>> Sorry, it is 6 AM now, I'll try your solutions next evening.
Everybody, thanks for the assistance and advice and sorry for vanishing. :-)
To get the actual task done, I've had -- before coming to play with
this thing -- to write another version of the tool, which did all work
with DB. While doing this I've found the problem (I think). It is the
half-dead HDD of my current substitute notebook -- which is all
covered with bad sectors and on heavy load reduces write speed to a
few kilobytes per second. Every single other machine where I've run my
tests works as fast as one can expect.
So, sorry for the noise and thanks again! No more benchmarks until I
get my MBP fixed.
Alexander.
------------------------------
_______________________________________________
lua-l mailing list
lua-l@lists.lua.org
http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/lua-l-lists.lua.org
End of lua-l Digest, Vol 3, Issue 76
************************************
