Matthieu Moy | 1 Mar 2005 16:03
Picon
Picon
Favicon

Re: Assertion failed

Tuomo Valkonen <tuomov <at> iki.fi> writes:

> Yes, we do not want the window to be relocated during a "detach".
> I'll have to see about doing something to that hook call, suc as 
> deferring it,

Actually, I think the hook is not called in the right place. It's
confusing for the programmer to get this callback "during a detach".
Perhaps there should be a pre- and a post- hook (if the post- hook is
possible, given the asynchrony of some ion functions. I don't know
enough about ion's internals to answer).

--

-- 
Matthieu

Tuomo Valkonen | 1 Mar 2005 19:25
Picon
Picon
Favicon

Re: Assertion failed

On Tue, Mar 01, 2005 at 04:03:17PM +0100, Matthieu Moy wrote:
> Actually, I think the hook is not called in the right place. It's
> confusing for the programmer to get this callback "during a detach".
> Perhaps there should be a pre- and a post- hook (if the post- hook is
> possible, given the asynchrony of some ion functions. I don't know
> enough about ion's internals to answer).

I see essentially two solutions to the matter:

1. Defer calling the hook functions until the mainloop. Things that
destroy objects, such as WRegion.rqclose, already do this. In this
case I'd like to do the same with a few other hooks as well that are
not supposed to go modifying anything. Unfortunately this is not 
possible in all cases. Another problem is that some of the parameters
will have at times been destroyed by the time the hook gets called.

2. Enter hooks that are not supposed to modify anything in a "protected
mode". This works for all hooks (and could replace the lists of safe
functions for resize and tabdrag mode), but is a lot more work, one
having to go through all the exports and see which ones should not
work in protected mode. Also it is a bit ugly that a function can
fail at run time being attempted to be called in protected mode. 
Simply deferring calling things is cleaner in this sense.

I don't yet know which solution I prefer.

--

-- 
Tuomo

(Continue reading)

Tuomo Valkonen | 1 Mar 2005 19:28
Picon
Picon
Favicon

Re: Assertion failed

On Tue, Mar 01, 2005 at 08:25:56PM +0200, Tuomo Valkonen wrote:
> 2. Enter hooks that are not supposed to modify anything in a "protected
> mode". 

A routine to defer processing until returned to the mainloop should 
of course be exported to the Lua side in this case.

--

-- 
Tuomo

Matthieu Moy | 1 Mar 2005 20:55
Picon
Picon
Favicon

Re: Assertion failed

Tuomo Valkonen <tuomov <at> iki.fi> writes:

> I don't yet know which solution I prefer.

I think 1. is both simpler to implement and simpler for the script
writter. Restricting the list of available functions is dangerous
because it's hard to know if a function call will not call another
function that will itself trigger a hook which itself will call a
forbidden function or something like this.

But you know ion's internal far better than me, so I'm not sure my
opinion is valuable ;-)

--

-- 
Matthieu

Tuomo Valkonen | 1 Mar 2005 21:18
Picon
Picon
Favicon

Re: Assertion failed

On Tue, Mar 01, 2005 at 08:55:40PM +0100, Matthieu Moy wrote:
>  Restricting the list of available functions is dangerous
> because it's hard to know if a function call will not call another
> function that will itself trigger a hook which itself will call a
> forbidden function or something like this.

It becomes a bit easier if we only allow in a given context "pure" 
functions that do not (seem to) modify program state. Of course it's
not foolproof, but much easier than trying to find exactly the functions
that are safe to call.

--

-- 
Tuomo

Matthieu Moy | 1 Mar 2005 22:34
Picon
Picon
Favicon

Submitting a darcs patch for ion3

Hi,

I've just "darcs get"-ed the latest ion3.

I wanted to submit my first patch, but "darcs diff" gives me a huge
amount of changes, because predist.sh did a lot of changes to files
considered as source by darcs.

What's the best way to track changes cleanly with ion and darcs ?

BTW, the patch was just, err ...

diff -rN old-ion-3/version.h new-ion-3/version.h
1c1
< #define ION_VERSION "(subversion checkout)"
---
> #define ION_VERSION "(darcs checkout)"

--

-- 
Matthieu

Tuomo Valkonen | 1 Mar 2005 22:54
Picon
Picon
Favicon

Re: Submitting a darcs patch for ion3

On Tue, Mar 01, 2005 at 10:34:34PM +0100, Matthieu Moy wrote:
> I wanted to submit my first patch, but "darcs diff" gives me a huge
> amount of changes, because predist.sh did a lot of changes to files
> considered as source by darcs.

Don't use the predist.sh method for development work. Check out, build
and install libtu and libextl separately. If you have, however, run
predist.sh, you can either

 1. Record the changes in just some files by passing the names of those
    files to record. Use 'darcs whatsnew -s' to view what files were changed.
    The files modified/deleted by predist.sh are libs.mk, libs.mk.dist,
    system.mk and predist.sh itself.

 2. 'darcs revert' the files that predist.sh modifies. (Libtu and libextl
    will now be expected to be installed on the system.)

--

-- 
Tuomo

Tuomo Valkonen | 1 Mar 2005 23:03
Picon
Picon
Favicon

Re: Submitting a darcs patch for ion3

On Tue, Mar 01, 2005 at 10:34:34PM +0100, Matthieu Moy wrote:
> What's the best way to track changes cleanly with ion and darcs ?

If you want to know what's happening, use the rss feeds. To update              
your copies of the repositories to include the latest changes, use darcs        
pull (-a -v). Again, don't use predist.sh, it's just for quick snapshot         
compiles and for creating the distribution tarballs.                            

--

-- 
Tuomo

Tuomo Valkonen | 2 Mar 2005 12:13
Picon
Picon
Favicon

Re: Assertion failed

On Tue, Mar 01, 2005 at 10:18:17PM +0200, Tuomo Valkonen wrote:
> On Tue, Mar 01, 2005 at 08:55:40PM +0100, Matthieu Moy wrote:
> >  Restricting the list of available functions is dangerous
> > because it's hard to know if a function call will not call another
> > function that will itself trigger a hook which itself will call a
> > forbidden function or something like this.
> 
> It becomes a bit easier if we only allow in a given context "pure" 
> functions that do not (seem to) modify program state. Of course it's
> not foolproof, but much easier than trying to find exactly the functions
> that are safe to call.

I have partly implemented this solution, and am leaning towards it,
although I haven't finally decided. Another problem with the other
solution is synchronisation with what else is going on. With all
the hook calls could be deferred to the main loop during a single
event processing call from there, one would sometimes infact have 
to defer stuff from the already deferred handlers to yet another
handler, or otherwise a hook might mess up the situation for the
next hook. In the protected mode solution the script writer would
similarly have to defer unsafe processing until the mainloop.
So, in the end, deferring hook calling in the end doesn't win much
for the script writer, and the code is more messy.

--

-- 
Tuomo

Tuomo Valkonen | 2 Mar 2005 13:37
Picon
Picon
Favicon

Re: The Wiki spam problem

On Sun, Feb 13, 2005 at 11:48:48PM +0100, Elvelind Grandin wrote:
> One other option would be using berlios.de but choosing some body else
> to setup/handle the wiki software.

It appears that they do not infact support python on the web server, so
running moinmoin there is not an option. Therefore some other (donated)
space is needed for the wiki, or some other wiki with sufficient anti-spam
measures must be tried. Mediawiki development releases also have spam block
regexp support, and it should be possible to periodiacally upgrade it too
automatically, but it seems an awful lot of work to set up (not exactly
meant to be customised), so at least I am not going to get into that.

--

-- 
Tuomo


Gmane