RE: [NeoStats-Devel] Perl on Win32

Justin Hammond wrote:
> > 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 lack of fields wasn't my concern,it was more with the fact you made a
specific distinction for field names. This means that while a C module
always uses client->name for servers and users a perl module would have to
user client->name for servers and client->nick for users. Makes for a more
complex API when fields such as the primary identifier of name are the ones
most commonly accessed if we have to name them differently.

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

Yes you insisted on this in the main C systems as well...

> BUT:

Oh...

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

Sounds great but you wouldn't let me create a FindClient for C :(

However, I am now going to write one and will ignore any protestations since
you are making a perl one :)

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

Pasting from first email:

> perl.c:load_perlmodule():PL_perl_destruct_level = 1;
> 
> Note, this is the first occurrence of this since it appears to be 
> repeated several times. It disassembles to something very unlike the C 
> code so I assume there is some macro magic happening here.

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

From shell:

perl --version

This is perl, v5.8.4 built for i386-linux-thread-multi

From configure:

Configuring for Perl Modules Now

checking for sed... /bin/sed
checking for perl... /usr/bin/perl
checking for Perl compile flags... ok
checking for /usr/bin/perl >= 5.8.0... Yes

From link:

Linking neostats:
[ERROR]
  gcc -I../lib/pcre -I../lib/curl -DNEOSTATSCORE -D_REENTRANT -D_GNU_SOURCE
-DT
  HREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include
-D_LARGEF
  ILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.8/CORE -I../lib/event
-g
  -O2 -DNDEBUG -fno-strict-aliasing -fno-strict-aliasing -o .libs/neostats
--ex
  port-dynamic -rdynamic auth.o bans.o bots.o channels.o commands.o
confuse.o c
  onfuselexer.o nsdba.o conf.o dl.o dns.o exclude.o hash.o ircstring.o
ircproto
  col.o ircsend.o ircrecv.o lang.o list.o log.o main.o match.o misc.o
modules.o
   nsevents.o helpstrings.o servers.o services.o signals.o sock.o support.o
tim
  er.o transfer.o users.o modes.o ctcp.o dcc.o nsmemory.o base64.o
numerics.o s
  ettings.o botinfo.o adnscheck.o adnsevent.o adnsgeneral.o adnsparse.o
adnsque
  ry.o adnsreply.o adnssetup.o /usr/bin/ld: cannot find -lperl
  collect2: ld returned 1 exit status
make[1]: *** [neostats] Error 1
make: *** [all-recursive] Error 1

Mark.