Well this is my first attempt with PIKE, although I am familiar with the LPC language some things seem to be a bit different in PIKE. My problem is that I am trying to include a file but I get the error that the file could not be read. I am assuming that somehow I am typing the directory wrong. I have tried many different ways including typing out the full directory name. I have kernel.pike which is the main pike program running in the base directory and the include works there with #include "includes/kernel.h". I tried this with my login sequence file which is located at /lib/obj/std/login.pike but it says it can not find the file. And for future reference I am sure I will be sending out alot of questions. Thanks all in advance.
--------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
There is nothing magic with #include, so I don't know what answer you expect. If it can't read the file then it can't read the file (no permission or couldn't find it). That's all there is to it.
/ Martin Nilsson (saturator)
Previous text:
2004-01-06 07:35: Subject: #include
Well this is my first attempt with PIKE, although I am familiar with the LPC language some things seem to be a bit different in PIKE. My problem is that I am trying to include a file but I get the error that the file could not be read. I am assuming that somehow I am typing the directory wrong. I have tried many different ways including typing out the full directory name. I have kernel.pike which is the main pike program running in the base directory and the include works there with #include "includes/kernel.h". I tried this with my login sequence file which is located at /lib/obj/std/login.pike but it says it can not find the file. And for future reference I am sure I will be sending out alot of questions. Thanks all in advance.
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
/ Brevbäraren
Actually, I am having a similar problem that defies all logic, so I don't know that it's strictly true to say there's no magic. My problem involves sTeam on the Solaris platform. The same code works just fine under linux, but when run on solaris, it's unable to find a large number of include files that are right there under its nose. I've tried a number of things (absolute paths, relative paths, etc) to no avail. And yes, the permissions are just fine.
It doesn't appear that the code has modified anything that would cause this to happen, but I won't rule it out yet. It's just very odd to have happen in the first place.
As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include <includefile.h>
Bill
There is nothing magic with #include, so I don't know what answer you expect. If it can't read the file then it can't read the file (no permission or couldn't find it). That's all there is to it.
/ Martin Nilsson (saturator)
Actually I have been using. #include "absolute filepath" . I have not enclosed the filename with <>'s since the -I command crashed pike through the command prompt. (FYI I am using Windows XP). As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include <includefile.h>
Bill
--------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
do backslashes need to be escaped? (ie \ should be \)? I've not got too much experience on the windows platform, but this might be the problem.
Bill
On Tue, 6 Jan 2004, Credence Shanden wrote:
Actually I have been using. #include "absolute filepath" . I have not enclosed the filename with <>'s since the -I command crashed pike through the command prompt. (FYI I am using Windows XP). As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include <includefile.h>
Bill
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
It's generally speaking more convenient to use / instead of .
/ Per Hedbor ()
Previous text:
2004-01-06 16:23: Subject: Re: #include
do backslashes need to be escaped? (ie \ should be \)? I've not got too much experience on the windows platform, but this might be the problem.
Bill
On Tue, 6 Jan 2004, Credence Shanden wrote:
Actually I have been using. #include "absolute filepath" . I have not enclosed the filename with <>'s since the -I command crashed pike through the command prompt. (FYI I am using Windows XP). As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include <includefile.h>
Bill
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
/ Brevbäraren
/.../ the -I command crashed pike through the command prompt. (FYI I am using Windows XP).
What error did you get?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-01-06 16:19: Subject: Re: #include
Actually I have been using. #include "absolute filepath" . I have not enclosed the filename with <>'s since the -I command crashed pike through the command prompt. (FYI I am using Windows XP). As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include <includefile.h>
Bill
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
/ Brevbäraren
I don't get an error. The application closes. Unless you want me to dig through the ugly error report that windows gives when an application crashes. But pike gives no error.
"Martin Stjernholm, Roxen IS @ Pike developers forum" 10353@lyskom.lysator.liu.se wrote:> /.../ the -I command crashed pike through the command prompt. (FYI I
am using Windows XP).
What error did you get?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-01-06 16:19: Subject: Re: #include
Actually I have been using. #include "absolute filepath" . I have not enclosed the filename with <>'s since the -I command crashed pike through the command prompt. (FYI I am using Windows XP). As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include
Bill
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
/ Brevb�raren
--------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
That's an error too. What I'd like to see is the stack at the time of the crash, but there's no easy way to do that in Windows unless you've got Visual Studio or something similar installed.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-01-12 05:37: Subject: Re: #include
I don't get an error. The application closes. Unless you want me to dig through the ugly error report that windows gives when an application crashes. But pike gives no error.
"Martin Stjernholm, Roxen IS @ Pike developers forum" 10353@lyskom.lysator.liu.se wrote:> /.../ the -I command crashed pike through the command prompt. (FYI I
am using Windows XP).
What error did you get?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-01-06 16:19: Subject: Re: #include
Actually I have been using. #include "absolute filepath" . I have not enclosed the filename with <>'s since the -I command crashed pike through the command prompt. (FYI I am using Windows XP). As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include
Bill
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
/ Brevbäraren
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
/ Brevbäraren
Actually, I am having a similar problem that defies all logic, so I don't know that it's strictly true to say there's no magic.
Got the problem some time ago with include and modules using -I and -M. IIRC, only the first arg was used on Linux.
Solved the problem using PIKE_MODULE_PATH and PIKE_INCLUDE_PATH.
The error is in the handle_include function. I think this is how it should look
if(local_include) { if(IS_ABSOLUTE_PATH(f)) path = combine_path("/",f); else { array(string) tmp=EXPLODE_PATH(current_file); tmp[-1]=f; path=combine_path_with_cwd(tmp*"/"); } }
/ Martin Nilsson (saturator)
Previous text:
2004-01-06 16:06: Subject: Re: #include
Actually, I am having a similar problem that defies all logic, so I don't know that it's strictly true to say there's no magic. My problem involves sTeam on the Solaris platform. The same code works just fine under linux, but when run on solaris, it's unable to find a large number of include files that are right there under its nose. I've tried a number of things (absolute paths, relative paths, etc) to no avail. And yes, the permissions are just fine.
It doesn't appear that the code has modified anything that would cause this to happen, but I won't rule it out yet. It's just very odd to have happen in the first place.
As for the poster's original question, I think that perhaps the include path might be incorrect. Try adding the path the include files are in with a -I command argument. That assumes you're using #include <includefile.h>
Bill
There is nothing magic with #include, so I don't know what answer you expect. If it can't read the file then it can't read the file (no permission or couldn't find it). That's all there is to it.
/ Martin Nilsson (saturator)
/ Brevbäraren
path = combine_path("/",f);
That should be
path = combine_path(f);
You shouldn't assume that the root is called "/". But since f is absolute, combine_path with one argument will do the right thing.
array(string) tmp=EXPLODE_PATH(current_file); tmp[-1]=f; path=combine_path_with_cwd(tmp*"/");
Ack! That should be
path = combine_path_with_cwd(dirname(current_file), f);
I think. Please avoid EXPLODE_PATH.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-01-12 16:49: Subject: Re: #include
The error is in the handle_include function. I think this is how it should look
if(local_include) { if(IS_ABSOLUTE_PATH(f)) path = combine_path("/",f); else { array(string) tmp=EXPLODE_PATH(current_file); tmp[-1]=f; path=combine_path_with_cwd(tmp*"/"); } }
/ Martin Nilsson (saturator)
The EXPLODE_PATH issue appears to be solved in 7.5. combine_path appears to be working fine even when the root is not called "/", but perhaps I just had luck on Windows...
/ Martin Nilsson (saturator)
Previous text:
2004-01-12 17:54: Subject: Re: #include
path = combine_path("/",f);
That should be
path = combine_path(f);
You shouldn't assume that the root is called "/". But since f is absolute, combine_path with one argument will do the right thing.
array(string) tmp=EXPLODE_PATH(current_file); tmp[-1]=f; path=combine_path_with_cwd(tmp*"/");
Ack! That should be
path = combine_path_with_cwd(dirname(current_file), f);
I think. Please avoid EXPLODE_PATH.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Arguments to combine_path() before the first absolute path are ignored.
/ Henrik Grubbström (Lysator)
Previous text:
2004-01-12 17:57: Subject: Re: #include
The EXPLODE_PATH issue appears to be solved in 7.5. combine_path appears to be working fine even when the root is not called "/", but perhaps I just had luck on Windows...
/ Martin Nilsson (saturator)
Well, in this case
combine_path("gurksallad",f)
would work since f is an absolute path, but it's not _correct_. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-01-12 17:57: Subject: Re: #include
The EXPLODE_PATH issue appears to be solved in 7.5. combine_path appears to be working fine even when the root is not called "/", but perhaps I just had luck on Windows...
/ Martin Nilsson (saturator)
pike-devel@lists.lysator.liu.se