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.

Since I cannot run the perl version on Win32 or *nix, you do not need to
worry about me offering any coding input whatsoever so if you want to ignore
this, I am not going to commit any fix for it. It is just something that
stood out making the perl API different to the main module API.

> As for distributing Perlxxx.dll in NeoStats, I think we would 
> have to go one step further and "redistribute" the entire 
> perl runtime. I'll go hunt and see if there is a cut down 
> version of the perl runtime as well.

OK.

> 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 used the MSI installation file from the activestate website. 

As did I.

> As far as the DLL load and unload, this was pretty much 
> untouched from Xchats version (minus a dialog box that pops 
> up if it couldn't load). I'll double check that I didn't 
> fudge the load/unload logic there.

OK.

> This global variable tells perl that when we destroy the perl 
> interpreter for that module, not to mess with the "global" 
> space, but only the local interpreter space, as we might have 
> other perl modules still loaded. The messages I seen on the 
> web say we should be including it a few times during the 
> construct, because perl will default it back to 0, which is bad. 
> 
> Anyway, most of Perl's variables and functions are MACROs to 
> the real calls... I believe this is to support different 
> threading options etc, which I assume is not relevent for us correct?

Well I run the main NeoStats loop on a thread but other than that we have no
other threading that I am aware of. Since it works for you, it may not be
relevant. I could run the main loop without a thread by using a yield
function so will try it to see if it makes any difference.

> 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.

Mark.