module Search

Warnings from Parser.LR.GrammarParser

MinGW is good

RE: Cannot compile pike 7.8 from git

Public.Standards.vCard broken by Pike-v7.9.5(from git)

Cannot compile pike 7.8 from git

pike complain "Unexpected end of file" when using #line in macro call

cast_to_program() and CompilationHandlers

At the conference in November, we had the following conversation (to quote 
mast's report):

"Bill talked about his attempts to separate resolver contexts, to be able 
to run different versions of an application in the same pike process. He 
would try to solve this with separate compilation handlers, similar to how 
the #pike compat system works."

Over the last few days, I've been playing with this idea a little bit 
more, and I think I can get at least part of the way to where I need with 
passing a CompatResolver object to compile() and friends.

One problem that I've noticed is that the compilation handler doesn't seem 
to concern itself with program loading (as opposed to loading from 
modules). Specifically, cast_to_program() consults the program path 
defined in the master and not the one that's used in the CompatResolver. 
Is that an oversight, or is that by design?

That is, shouldn't the following line:

  foreach(pike_program_path, string path)
       if(program ret=findprog(combine_path(path,pname),ext,handler,mkobj))
         return ret;

be something like:

  foreach(handler->pike_program_path||pike_program_path, string path)
       if(program ret=findprog(combine_path(path,pname),ext,handler,mkobj))
         return ret;

?

Secondly, I'm not sure if there's a way to completely override compile() 
and the like, as it seems as though the system prefers to use the 
originally defined efun even after I've added compile using add_constant. 
It does get used in the rare cases where my code calls compile() 
explicitly, but otherwise it seems as though that's not the case (and I've 
made sure that there aren't any cached copies of programs in the programs 
mapping in master().

Any thoughts?

Bill

Re: Good code? Bad code? Horribly horribly ugly code?

2012/1/16 Per Hedbor () @ Pike (-) importmöte för mailinglistan
<6341 <at> lyskom.lysator.liu.se>:
> Well.  I would rewrite it using () instead of {}. :)
>
>> !catch(throw(ip!=gethostbyname("hostname.domain.com")[1][0]))

Hmm, wasn't aware of that. Learn something new every day!

> Also, if hostname.domain.com happens to have multiple IP:s the results
> could be somewhat random. :)
>
> Anyway, for clarity I would probably avoid that construction.

I run the nameserver in question, and that hostname is specifically a
way to reference that IP, so that's safe.

How would you go about this? Ideally without a splash of temporary
variables, and self-contained.

ChrisA

Re: Good code? Bad code? Horribly horribly ugly code?

2012/1/16 Mirar @ Pike  importmöte för mailinglistan
<6341 <at> lyskom.lysator.liu.se>:
> My only problem is only that throws are generally rather expensive
> compared to an if. :)
>

Heh! It's called once only, in response to a user command, and only on
one particular parameter, so I'm not too concerned about cost. But
yes, that is definitely a consideration.

ChrisA

Good code? Bad code? Horribly horribly ugly code?

I just wrote this into my MUD. It's beautifully elegant and
disgustingly ugly... at the same time.

else if (!catch
{throw(ip!=gethostbyname("hostname.domain.com")[1][0]);})
location="descriptive location";

This is in a long chain of "else if" checks on an IP address (most of
which are, for instance, prefix checks for "192.168"), and it looks up
the hostname to see if the IP matches it. In the event of DNS failure,
either gethostbyname will return 0, or it'll return something that
doesn't have the proper arrays to index - either of which will throw
an exception, causing the if to fail and the next else to be checked.
If the lookup succeeds and returns something different from the IP,
then the integer 1 will be thrown and the if will fail. If it does
match, though, the integer 0 will be thrown - which is perfectly legal
- and the "!catch {}" will be true, and the location will be set.

Would you, if you saw this code in a production environment, be scared
or delighted? I'm suspecting the former...

ChrisA