Stat in
Dan Sugalski
only integer queries so far. (Two of which unconditionally return -1
anyway) But... at least you can go look to see if a file exists. :)
We can add more to this as we go, but this should be enough to get Jens going.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jens Rieks
> We can add more to this as we go, but this should be enough to get Jens
> going.
Shall I write it?
The current parrotlib bytecode uses C<open> to test if a file exists, I'll
modify the code to use C<stat> then.
Or should I write those functions in C?
The _parrotlib bytecode is working, but it disables DOD ATM :-(
Nevertheless, all tests except
t/pmc/timer.t 2 512 7 2 28.57% 6-7
are passing; the timer tests are generally not working with DOD turned off (I
don't know why).
My problem is that I do not know much about the DOD system; I have no clue how
to debug this, or what I might have done wrong to trigger this behavior.
Test results with DOD enabled:
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/library/dumper.t 13 3328 13 13 100.00% 1-13
t/pmc/managedstruct.t 1 256 5 1 20.00% 5
t/pmc/mmd.t 1 256 10 1 10.00% 8
t/pmc/nci.t 6 1536 34 6 17.65% 21 28-31 33
t/pmc/sys.t 1 256 1 1 100.00% 1
1 test and 57 subtests skipped.
Failed 5/104 test scripts, 95.19% okay. 22/1559 subtests failed, 98.59% okay.
(dumper.t seems to fail because of its havy use of load_bytecode)
If you run the tests manually (without --gc-debug), only t/pmc/sys_1.imc fails
(with "list structure chaos!")...
jens
Dan Sugalski
>On Tuesday 25 May 2004 01:35, Dan Sugalski wrote:
>> We can add more to this as we go, but this should be enough to get Jens
>> going.
>Theres no stat op yet, is there?
Ah, dammit--I was too careful with the commit and missed some files.
Update to CVS and you can get:
file existence
Filesize (up to a point--int-only, so big file sizes fail)
dates (create, modify, change, access, and backup)
UID & GID
whether it's a directory or a device.
>are passing; the timer tests are generally not working with DOD turned off (I
>don't know why).
Hrm. Something worth tracking down--might be an unanchored pmc
somewhere or something of the sort.
Leopold Toetsch
> The _parrotlib bytecode is working, but it disables DOD ATM :-(
The problem is that now the runloop is entered already in the
lexer for the first time (for loading includes). When entering the
run loop the first time, the stack top is set, which is now somewhere in
imcc code.
When the "real" code is run then the stacktop isn't set again.
(see RESUME_INITIAL in src/interpreter.c)
The following patch fixes the problem:
--- parrot/src/library.c Tue May 25 12:01:37 2004
+++ parrot-leo/src/library.c Tue May 25 14:44:15 2004
@@ -68,6 +68,8 @@
PMC *sub, *prop;
STRING *str, *name;
char *csig;
+ INTVAL resume = interpreter->resume_flag;
+
va_start(args, func_name);
if (!init_done) {
@@ -96,6 +98,7 @@
ret = Parrot_runops_fromc_arglist_save(interpreter, sub, csig, args);
va_end(args);
+ interpreter->resume_flag = resume;
return ret;
}
> jens
leo
Jens Rieks
On Tuesday 25 May 2004 14:52, Leopold Toetsch wrote:
> The following patch fixes the problem:
Wow, thank you very much, Leo! :-)
The code is now working as expected. I'll now add a makefile rule to generate
runtime/parrot/include/parrotlib.pbc from
runtime/parrot/library/parrotlib.imc
Is it okay to use runtime/parrot/include for generated files only?
I think its best to move all handwritten files to runtime/parrot/library.
The next thing I'll do is to make the parrotlib.pbc location configurable.
Then, we can use parrotlib to retrieve the location of the ICU data files.
Parrotlib already uses the environment variable PARROT_RUNTIME_ROOT which, if
set, is used to locate the "runtime/parrot" directory. A sensible default
value is nevertheless required.
BTW, I think its best to also move the blib directory to runtime/parrot, at
least the files that are used at runtime.
jens
Dan Sugalski
>Hi,
>
>On Tuesday 25 May 2004 14:52, Leopold Toetsch wrote:
>> The following patch fixes the problem:
>Wow, thank you very much, Leo! :-)
>
>The code is now working as expected. I'll now add a makefile rule to generate
>runtime/parrot/include/parrotlib.pbc from
>runtime/parrot/library/parrotlib.imc
Cool. After this what I'd like to do is come up with a scheme to
embed the generated library directly in the parrot executable.
That'll save us from having to figure out where the library that
figures out where libraries are is.
Leopold Toetsch
> The code is now working as expected.
Not quite. Running PBCs that e.g. C<.include "file"> don't work
any more[1].
There are packfile issues now due to the changed execution order.
Until this is resolved I'd vote for still disabling _PARROTLIB.
leo
[1] make testr
make fulltest
Jens Rieks
On Wednesday 26 May 2004 14:27, Leopold Toetsch wrote:
> Jens Rieks <par...@jensbeimsurfen.de> wrote:
> > The code is now working as expected.
>
> Not quite. Running PBCs that e.g. C<.include "file"> don't work
> any more[1].
> There are packfile issues now due to the changed execution order.
Oops, shame on me. Last time I've checked this, everything was working. Maybe
a config error or something like this :-(
> Until this is resolved I'd vote for still disabling _PARROTLIB.
I've disabled it for ".include"; the parrotlib code does the same as then the
original C code path for the hardcoded directory locations.
I'll write a C version of the dynext locating code too, as a working C version
is also required for miniparrot (at least, I think so?)...
> leo
jens