RE: [NeoStats-Devel] Perl on Win32

> Justin Hammond wrote:
> > > I thought you were still getting it running generally otherwise I 
> > > would have looked into it.
> > >
> > All that's actually left is to implement the few remaining 
> > NeoStats API's now. The actual embedding of Perl is complete, 
> > and  we have a pretty "complete" support for perl modules now.
> 
> OK, might be time to raise a concern that perl support makes 
> a specific
> distinction between Servers and Users which I have tried to 
> avoid as much as
> possible in the main core. Where you copy the client structs, 
> you seem to
> have used two paths. One for servers and one for users. The 
> original Client
> struct is a generic base with extenstions for server and user 
> fields that do
> no fit the combined structure. E.g. you assign the generic 
> name to nick in
> user when there is no need. I appreciate there are 
> differences in the perl
> support, but since most things come from a source to to a 
> target, a single
> name field makes life simpler for any module accessing a 
> Client struct.
> 

Hi,
I thought about this and actually my first version just encoded the entire
client struct ignoring if it's a user/server. The  problem I found is that
perl->C->perl calls are expensive... So I got a bit of speedup by not
converting everything over. 

The other thing was that perl API I guess is meant to be a "simple" api for
modules. I wanted to keep some distinction for this clients to make authors
think about what data they want (Find(user/server/chan).

BUT:
I've been playing with a thing called Tie'd hashes in perl, where you can
have the perl variable reflect the actual C variable at that point in time
(right now, we make a copy of the varibles in perl, so if the C variable
changes, its not reflected in the perl variable unless you call FindUser etc
again). 

The problem is it's a bit of black magic (the functions are actually called
hv_magic!) and not well documented. This tie'ing of variables would be
perfect for the SET interface, because you can create C callback functions
when a variable is read or written. If I can figure this out, then I will
actually try to convert the whole finduser interface to this and we can
revert to just a findclient replacement (and we don't suffer as much in
terms of performance, because the perl->c->perl calls are only made when you
access that variable and that's it)




> > Well, I don't know how you isntalled Perl, does the standard 
> > perl.exe run with no problems? As mentioned above, perl needs 
> > a lot of its support files to operate, so this could be the 
> > problem if you "fudged" it. 
> 
> I have it working as designed now. It failed to set PATH 
> correctly. Having
> resolved this, the same problem with segfault occurs. As I 
> said before, I
> have no idea where to start looking so cannot offer any more 
> information at
> present.
> 

I havn't done much to look into this yet, but wondering if you could tell me
which actual PL_perl_destruct_level assignment crashes (as you pointed out
there are numerous ones in the load_module, it would be helpful to know
which one crashes. 


> > Now what finally pisses me off is that it works for me, but 
> > not for you. Ok, I'll go and do more research on this and get 
> > back to you shortly.
> 
> OK. Let me know if you want me to test anything. 
> 
> As an aside, the default configure includes perl causing it 
> to fail on my
> Debian (Sarge?) box. Fails at link time. I have not looked 
> into why at all,
> I just disabled it. I assume configure could check the link 
> problem prior to
> automatically enabling something that will ultimately fail.
> 

Could you paste me the actual linking error (and any compile warnings as
well), as well as the perl version you are using. It should only try to link
with perl 5.8.x versions and I already know that perl 5.8.1 had a problem
which I fixed once already.

Configure should be checking the perl versions, so it must think you have
perl 5.8, it would be interesting to know what it thinks that it is.

Thanks