EPIC 0.4.0 and 0.5.0 includes not working

rsliotta wrote on Wed Aug  9 19:18:04 MEST 2006:

Team,

I just upgraded to Eclipse WTP 1.5 that includes eclipse 3.2.  I also 
upgraded EPIC to .0.4.0 and 0.5.0.  It looks like the includes are no 
longer being added to the runline of the perl.  Any ideas?  I just use a

straight run and not the CGI run.

Can you help?

Thanks,

Bob

jgangemi wrote on Wed Aug  9 19:29:03 MEST 2006:

have you double checked the project's include path (under properties?)

also, just as an fyi, if you install 0.4.0 and 0.5.0, the development version
will be loaded first, if you want to use just the stable version, de-activate
the 0.5.0 plugin.

rsliotta wrote on Wed Aug  9 20:07:27 MEST 2006:

Yes.  I have two includes and they are both present in the .include files.
 I can see them in project properties as well.

Either version would work for me I just tried 0.5.0 to see if it was fixed.
 I do see the perl epic debugger in the list of libs.  That looks new to
me.  It looks like it is adding that and not my list.

Maybe it has something to do with the new features that are configurable
on the run.

Thanks for responsing so quick.

jploski wrote on Wed Aug  9 20:56:35 MEST 2006:

So you run a script like this one:

foreach $i(@INC) { print "$i\n"; }

and the include paths from the project properties are not showing up? Which
platform? Can you post the entered include paths here?

rsliotta wrote on Wed Aug  9 21:01:52 MEST 2006:

This is the output when I run it.....

Can't locate ProcessInitializer.pm in @INC (@INC contains: C:/Program Files/eclipse/plugins/org.epic.debug_0.5.0/
/usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8 .) at C:/My Personal Data/My CVS/xShipManager/workspace/test_xsl.pl
line 3.
BEGIN failed--compilation aborted at C:/My Personal Data/My CVS/xShipManager/workspace/test_xsl.pl
line 3.


Until I upgraded, it also contained the information in the .includepath



  
  



This application will not even run without them.

jploski wrote on Wed Aug  9 21:44:40 MEST 2006:

The entered include paths likely point to non-existing folders and are therefore
skipped by EPIC. Insert the volume letter (c:) if they are intended to be
absolute paths. If they are meant to be project-relative, remove the slash
from the beginning.

rsliotta wrote on Wed Aug  9 21:51:44 MEST 2006:

Nope.  Cygwin....

If I roll back to 3.1 and 0.3.0, it works properly.  It's definiately the
upgrade.  

I have been using e-p-i-c since the beginning.  I am not new at this.  I
am 99% sure something is now broken.  PERL5LIB has to be in cygwin reference,
not windows.  Always has been...

Thanks

jploski wrote on Wed Aug  9 22:03:06 MEST 2006:

Ok, I think what is going on here is EPIC rejecting these paths as invalid,
using Windows semantics (which is indeed a change from 0.3), while they
are required in that exact form by the Cygwin version of Perl. I'll fix
it so that the paths are not filtered out.

jploski wrote on Wed Aug  9 22:11:37 MEST 2006:

One more thing: I see a piece of code in the launcher which translates Windows
paths into Cygwin paths if the interpreter type is "Cygwin" in EPIC Preferences.
So c:/foo/bar would become translated into /cygdrive/foo/bar.

Can you try setting the Perl interpreter type to Cygwin and adjusting your
@INC path just to see if that would work? (Just curious - I don't like this
preference setting and will pursue the other solution anyway.)

rsliotta wrote on Wed Aug  9 22:06:44 MEST 2006:

Yes.  You are correct.  I added a windows path and it works.

I just cannot actually path this since it is a symlink on the cygwin side.

Thanks...  Awesome response!

rsliotta wrote on Wed Aug  9 22:24:24 MEST 2006:

In my case, /cvs/xShipManager/xShipManager/lib in cygwin is actually

/cygdrive/c/MyPers~1/MyCVS~1/xShipManager/xShipManager/lib

I tried it.  It does not seem to work.  I think it is getting mangled somehow.

rsliotta wrote on Wed Aug  9 22:29:12 MEST 2006:

I think if you just pass them as is to the PERL intrepeter colon(:) separated
will work.  The POSIX environment of CYGWIN should hadle it properly.


BTW.  If you ever need testers, I use this heavily.  I am not big on the
debugger yet, but I use verything else.

BTW again.  I have a need for a localized web server for this environement.
 Eclipse now includes tomcat, but this is not good for CGI development where
I need to include HTML besides the CGI.  Your  runner is good for the CGI,
but that is not always the picture.  I am toying with lighttpd for this,
but a simple integrated server to your toolset would be awesome!

It would need to be able to do aliases like apache and not much else.

I am an architect for my company and if you need any design work, let me
know!

jploski wrote on Wed Aug  9 22:54:30 MEST 2006:

Thanks for the help offer. I am going to write some introductory documentation
for new developers soon, which you might find useful.

I think EPIC's CGI runner (which uses an embedded Brazil web server) can
also serve plain HTML files.

rsliotta wrote on Wed Aug  9 22:30:57 MEST 2006:

One last question.  Sorry to be a pest.  Any ETA on a fix?

If it will be a while, I will consider rolling back.  It will be a big job,
but I don't want to pressure.  If it is quick, I will wait.

jploski wrote on Wed Aug  9 22:51:14 MEST 2006:

Check if the just released 0.4.3 works. It should pass through the paths
unchanged (do not set the interpreter type to 'Cygwin' this time).

rsliotta wrote on Wed Aug  9 23:08:23 MEST 2006:

The good news is now I can see them.  It is rewriting them though...

As PERL standard:

Can't locate ProcessInitializer.pm in @INC (@INC contains: C:/My Personal
Data/My CVS/xShipManager/cvs/xShipManager/build_common/resources C:/My Personal
Data/My CVS/xShipManager/cvs/xShipManager/xShipManager/lib C:/Program Files/eclipse/plugins/org.epic.debug_0.4.0/
/usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8 .) at C:/My Personal Data/My CVS/xShipManager/workspace/test_xsl.pl
line 3.
BEGIN failed--compilation aborted at C:/My Personal Data/My CVS/xShipManager/workspace/test_xsl.pl
line 3.


As PERL Cygwin:

Can't locate ProcessInitializer.pm in @INC (@INC contains: /cygdrive/c/my
personal data/my cvs/xshipmanager/cvs/xshipmanager/build_common/resources
/cygdrive/c/my personal data/my cvs/xshipmanager/cvs/xshipmanager/xshipmanager/lib
C:/Program Files/eclipse/plugins/org.epic.debug_0.4.0/ /usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8
.) at C:/My Personal Data/My CVS/xShipManager/workspace/test_xsl.pl line
3.
BEGIN failed--compilation aborted at C:/My Personal Data/My CVS/xShipManager/workspace/test_xsl.pl
line 3.


The bad news is it is still rewriting them.

They should be:


/cvs/xShipManager/build_common/resources
/cvs/xShipManager/xShipManager/lib


On the Brazil thing, I would need to be able to add aliases like /alias
= /cvs/xShipManager/folder/otherfolder  Not sure if that is doable.

luelljoc wrote on Thu Aug 10 08:07:27 MEST 2006:

Hi Robert,

adding a handler to Brazil to handle Redirect should not be a big problem.
Brazil supports hadlers (for the request) and filters (for the response)
that can be added to the brazil configuration (in the EPIC case to the brazil_cgi_templ.cfg).
I might have an redirect handler already from a different project.

Bye
Jochen

rsliotta wrote on Thu Aug 10 16:33:14 MEST 2006:

Hi.  This could be very useful to me.  Do you have more information where
or how to implment such a thing?  I have not made use of the CGI launcher
and at this time I only use the standalone.

I have tried to use the launcher in the past and have had issue whereby
my HTML root and my CGI root are on paralell folders.  I keep CGI's out
of the HTML root for good reason as you can imagine and only use scriptalias
directives in Apache to access them on my servers.

If I can configure Brazil to do the same that would be music to my ears.

I now use lighttpd and use it's configuration to redirect, but it is outside
of eclipse and a bother.

I created some some external launchers to manage it, but it is not portable
for anyone else.

Any help or guidance you can provide would be awesome.

Thanks

jgangemi wrote on Thu Aug 10 16:50:15 MEST 2006:

all of the interactions w/ brazil seem to occur in the CGITarget in the
debug package, so that should be a good place to start. 

luelljoc wrote on Thu Aug 10 17:12:51 MEST 2006:

Hi,

actually it should be much easier, without having to make changes to the
EPIC code.

Look at the following handler:
http://paw-project.cvs.sourceforge.net/paw-project/paw-project/src/org/paw/handler/RedirectHandler.java?view=markup

This handler could be used without changing it.
The handler takes a filename as argument which contains tab separated values
for redirecting URLs.

Lines consist of Regular expressons separated by TAB:

TAB

Here is an example (backreferences are also possible):
## Redirects search.msn.* to www.google.com
^http://search\.msn\..*?/results.asp\?.*?q=([^&]*)	http://www.google.com/search?q=$1


The handler has to be compiled against the brazil and gnu-regexp libs and
availabel in the classpath.
Then it should only be necessary to change the file brazil_cgi_templ.cfg.
I haven't tried it but I'm quite confident that it will work.

The following line should be changed from

main.handlers = cgi file
to
main.handlers = redirect cgi file

and the following lines added:

redirect.class=org.paw.handler.RedirectHandler
# This is the path to the file containing the redirect rules
redirec.rules=c:/redirects.txt

That should be it.

Bye
Jochen

rsliotta wrote on Thu Aug 10 22:34:47 MEST 2006:

Hmm...

Based on the beginning of this thread, If I just use the standard brazil
to run my CGI programs, shoud it use the project's include path?  It does
not seem to be doing so.

I Added PERL5LIB to the CGI variables, but it is being ignored somehow by
the launcher.  If I create a small program that prints the environment,
it is there.  Somehow it is not being used though.....

jploski wrote on Thu Aug 10 14:30:20 MEST 2006:

The rewriting now seems to occur because the paths starting with '/' are
reported as relative by Java under Windows :-(

I will have a closer look. In the meanwhile, you can try a simple workaround
by specifying the paths using -I on the "Arguments" tab under "Perl arguments"
in the launch configuration. This does not solve the entire problem because
the include paths are then still wrong during syntax checks. The ability
to specify command-line Perl arguments for a launch configuration is new
in 0.4.x.

jploski wrote on Thu Aug 10 15:28:08 MEST 2006:

Having examined the code which depends on the content of the include path
more closely, I see a serious problem with my envisioned "no-rewriting fix".
Basically, the paths entered under project properties are supposed to be
used in different contexts, by both Perl and EPIC:

1. They are passed to Perl for syntax checking and execution of the scripts.
2. They are used by EPIC's "Open Subroutine" feature to search for modules.

Obviously, if we allow Cygwin-compliant paths to be entered there, syntax
checking and execution will work, but "Open Subroutine" will break. On the
other hand, if we demand Windows paths, "Open Subroutine" will work - provided
that the folders can indeed be located somewhere in the Windows file system
and not just in the Cygwin world. On the other hand, "Open Subroutine",
as well as possibly other future functions which interpret @INC as a list
of paths (not of arbitrary strings resolved by Perl) will break.

Under these considerations and the assumption that most people use ActiveState's
Perl under Windows, the "Perl interpreter type Cygwin = rewriting" option,
appears as a reasonable trade-off. The "native Perl" people can benefit
additionally from the current interpretation of the @INC list. For example,
we could actually check whether the entered directories exist and warn about
missing ones, or (better) replace the current crude @INC dialog with a standard
dialog for entering an ordered list of paths.

Would entering your Cygwin paths in the "Perl Arguments" dialog mentioned
in the previous message and as the "Perl executable" preference (to support
compilation) be acceptable? I am also curious why you need to use the Cygwin
version of Perl? I tend to think that your case is quite untypical - not
because you are just using Cygwin, but because you are also using paths
not mappable to Windows paths.

rsliotta wrote on Thu Aug 10 16:28:44 MEST 2006:

On this matter, it turns out I just got it working by using the "standard"
interpreter and using the windows paths.  I still point to the Cygwin perl
though.  

I am not sure what happened yesterday, but when I entered the includes via
properties and use the browse button and it works.  Good for all of us.
 Must of had some kind of typo (Embarrassed).

In answer to your question about the cygwin environment:

I am developing an application that works on both UNIX and windows by utilizing
the cygwin environment for it's posix and forking capabilities.  

With this approach, it allows me to create a standard build for both platforms.

Now here's what I do that's important:

The include is a lib path the points to a bootstrap library.  The library
does all the work to figure out the platform stuff and cygwin/UNIX/Windows
paths.  My only issue is finding the library for EPIC for whatever interpreter.
 So if I can find the library via windows paths it will work fine.

So in the end, the interpretr really does not matter, nor the cywin.  The
cygwin only comes into play when the perl actually starts after the first
BEGIN statement that lives in the lib I am trying to find.

This is where all the magic happens.

Isn't portability great?

I thank you for your help...