all : $(O_FILES) test_prog
test_prog: test_main$(O) $(O_FILES)
! gcc -o test_prog $(O_FILES) test_main$(O) -lm
test_main$(O): $(H_FILES)
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
1.11
+++ basic_opcodes.ops 2001/09/13 08:27:40
@@ -219,7 +219,7 @@
// INC Nx, nnn
AUTO_OP inc_n_nc {
- (NV)NUM_REG(P1) += P2;
+ NUM_REG(P1) += P2;
}
// DEC Nx
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
rather than
inline. Isn't that a bit OTT though? I can understand blocking HTML
messages and attachments but I prefer to send patches as attachments
as it ensures that trailing blank lines and such like are properly
preserved and basically that the patch arrives completely intact.
Tom
--
Tom H
= {
enc_native,
string_native_compute_strlen,
string_native_max_bytes,
@@ -63,4 +63,5 @@
string_native_chopn,
string_native_substr,
};
+return sv;
}
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 13, 2001 at 09:35:33AM +0100, Tom Hughes wrote:
> > BTW I have had to resend this because my first attempt was bounced
> > apparently for having the patch as a text/p
@@ -47,7 +47,7 @@
/* Offset and length have already been "normalized" */
string_grow(dest, src->strlen - length);
-Sys_Memcopy(dest->bufstart, src->bufstart + offset, length);
+Sys_Memcopy(dest->bufstart, (char *)src->bufstart + offset, length);
string_copy(STRING* s)
> > void string_destroy(STRING *s)
>
> *cough* Namespace pollution *cough*
>
> These should proably all be prefixed...
Especially since all function names starting with str are strictly
speaking reserved to ANSI/ISO for future expansion of the string.h
facili
basic_opcodes.ops
--- basic_opcodes.ops 2001/09/16 15:49:22 1.17
+++ basic_opcodes.ops 2001/09/16 16:27:30
@@ -564,7 +564,7 @@
/* NOT_i */
AUTO_OP not_i {
- INT_REG(P1) = ! INT_REG(P2);
+ INT_REG(P1) = ~ INT_REG(P2);
}
/* OR_i */
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
t a STRING* which would
then be consistent with the nprintf interface.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
? xxx
Index: parrot.h
===
RCS file: /home/perlcvs/parrot/parrot.h,v
retrieving revision 1.8
dif
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>
> Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Sep 13, 2001 at 09:35:33AM +0100, Tom Hughes wrote:
> > > BTW I have
kfile.c: In function `PackFile_Constant_unpack':
packfile.c:1233: warning: unused variable `i'
packfile.c: In function `PackFile_Constant_dump':
packfile.c:1358: warning: unsigned int format, long unsigned int arg (arg 2)
The attached patch will clean up those warni
reporting 7.14M ops/sec on a 200MHz K6 running
linux with the interpreter compiled -O3. That's about twice the
speed that I get without any optimisation.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
I'm afraid. I've just clocked 42.86M on an Athlon/1333 though ;-)
At the other end of the scale a P5/90 manages 2.91M ops/sec.
Taken together (and with the K6/200 time) that is something fairly
close to linear scaling with clock speed on x86 machines although
the K6/200 seems to be beating
the same page here.
Not that I recall. I thought that was what strings.pod was...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
to, as an array is all one object.
Practically speaking I think it will work on every system that I can
think of at the moment but who knows what wierd things are out there...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Jason Gloudon <[EMAIL PROTECTED]> wrote:
> The "stacktest" patch will fail on the current CVS source, due to a bug in
> push_generic_entry.
This looks good to me so I have committed it. Thanks for spotting it!
Tom
--
d
> see what I missed. Probably some odd dependency or timing issue
> somewhere. (It's emacs fault! Yeah, that's the ticket! :)
I'd already patched it up, so I've just committed my fix...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
coding
tasks) will be character set based rather than encoding based.
Other than that it looked quite good and I'll probably start looking at
bending the existing code into the new model over the weekend.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
e the algorithm used and the logic behind it on the
list when I implemented it.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> Other than that it looked quite good and I'll probably start looking at
> bending the existing code into the new model over the weekend.
Attached is my first pass at this - it's not full
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> Attached is my first pass at this - it's not fully ready yet but
> is something for people to cast an eye over before I spend lots of
> time going down the wrong path ;-)
Before anybody e
once we get
> PMCs.
Both string and numeric versions of the comparison ops exist...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
>
> >Attached is my first pass at this - it's not fully ready yet but
> >is something for people to cast an eye over before I s
ding from ASCII to
Latin-1? and back again? If we're not careful both ends will implement
both translations and we will have effective duplication.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
st encoding the argument in the chosen encoding (which
can be the default encoding for the char type if you want) and then setting
the type and encoding of the resulting string appropriately.
Equally ord() is decoding the first character of the string to get a
number.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
James Mastros <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 29, 2001 at 11:20:47PM +0000, Tom Hughes wrote:
>
> > I suspect that the encode and decode methods in the encoding vtable
> > are enough for doing chr/ord aren't t
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
> >
> > >Attached i
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 27, 2001 at 04:23:48PM +0100, Tom Hughes wrote:
> > The encoding_lookup() and chartype_lookup() routines will obviously
> > need to load the relevant libraries on the fly w
able of
names which it will look up as it is loaded rather than the current
hard coding of name to number mappings in the byte code.
So all I need now to make all this work is hash tables and dynamic
code loading ;-) Any volunteers...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
10.050130
gosford [~/src/parrot-cg] % ./examples/assembly/mops
Iterations:1
Estimated ops: 3
Elapsed time: 4.515596
M op/s:66.436413
So there is a small speed up for the interpreted version, but nothing
like the three times speedup you had. The compiled version has actually
managed to get slower...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
hand without building it
from source so I haven't tried that as yet.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
with some
giving much greater improvements than others.
One other thing that I did notice is that there is quite a bit of
fluctuation between runs on some of the machines, possibly because
we are measuring real time and not CPU time.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
l be and that it can be used directly instead of
calling string_length().
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
amendment to this to make string_index use
the encoding routines instead of assuming a single byte encoding.
I have also renamed _string_index to string_index as function names
that start with an underscore are reserved to implementors by the C
standard.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
be visible
across more than one file - if it is only needed in the file that is
implrmenting the scalar class then it can be put there.
In fact many compilers will inline small static functions anyway
even without an explicit hint in the source.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
in
patching file Types_pm.in
patching file assemble.pl
patch: unexpected end of file in patch
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
least is missing and this I can't
run any tests.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
me know how it works for
> you...
It builds and tests cleanly for me now (linux/x86).
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
go you are unlikely to notice which behaviour a given
platform has chosen.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
test harness (trans-test.c) which I have used to validate the
transcoder to a certain extent.
This patch also fixes a bug in the existing native strings where
string_native_compute_strlen was returning the number of bytes that
had been allocated rather than the number that were in use.
Tom
--
er is wrong, at least if you allow U+ to U+10 as your
character space which is what I did - any character over U+ needs
four bytes.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
estion (which I think Simon was hinting at with his
cryptic comment) is whether the native encoding is fixed when parrot
is built or can change on the fly as they user changes their locale
settings. If it's the latter than conversion to and from native will
have to work by loading an approp
t fields.
The Cray was the canonical example of a problem machine that I had
in mind - if I recall correctly even char is 8 bytes there isn't it?
Bit fields are no use as you can't have a pointer to a bit field.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
ch also adds support for \x escapes in strings as it is
difficult to write unicode string constants without that.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
Index: Assembler.pm
===
RCS file: /home/perlcvs/parrot/P
o unicode even if the native string is
first, so the transcoding will have to be done at the string layer
rather than the strnative/strutfn layers I think.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
ill not clear what
encoding those are supposed to map to. I can understand the
following mappings:
N => enc_native
U => enc_utf32
but what is A supposed to map to exactly? or is the assembler
supposed to mangle an A string into an N or U string and then
put it in the bytecode in one of th
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
? t/tom.pasm
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.36
diff -u -w -r1.36 basic_opcodes.ops
--- basic_opcodes.ops
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 10, 2001 at 12:49:50AM +0100, Tom Hughes wrote:
> > Attached is a patch to add string comparison ops, along with the
> > necessary infrastructure in the string c
fter we get done comparing it.
It creates a new string if the second argument is null, and overwrites
the second argument otherwise, so in this case it will create a new string.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
this
+case a UTF-32 copy will be made of each string and these copies will
+be compared.
+
B:
To format output into a string, use
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
oesn't, but neither does anything else
that creates temporary strings in a different encoding ;-)
As we're using garbage collection we shouldn't need to do an explicit
free though surely - in fact I'm not quite sure why string_destroy
even exists...
It's easy enough to
Index: string.t
===
RCS file: /home/perlcvs/parrot/t/op/string.t,v
retrieving revision 1.8
diff -u -w -r1.8 string.t
--- string.t 2001/10/05 11:46:47 1.8
+++ string.t 2001/10/10 08:42:55
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test
Thinking about it though, that is my code as well so it doesn't really
prove anything very much ;-)
So the question is, are strings subject to GC or not? If they aren't
then I'll knock up a patch to add the string_destroy calls.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 10, 2001 at 12:49:50AM +0100, Tom Hughes wrote:
> > Attached is a patch to add string comparison ops, along with the
> > necessary infrastructure in the string c
In message <[EMAIL PROTECTED]>
Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
> Assignment, not comparison. (Plus formatted for coding standards)
Committed. The tests should really have caught this, so I'm going to
do some work on them to make them more comprehens
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>
> Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
>
> > Assignment, not comparison. (Plus formatted for coding standards)
>
> Commit
been committed...
The message is <[EMAIL PROTECTED]>.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> opcheck.pl: Found 39 errors.
>
> Is opcheck.pl wrong, or is the optable wrong? Would like a volunteer
> to fix up which it is.
I''ll take a look...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
ixes a 'use of undefined value' warning from opcheck.pl
when no errors are found, and makes process_opfunc.pl abort with
an error if opcode_table and basic_ops.ops don't match.
Finally it tidies up the comments in basic_ops.ops so that they
are all in the same form.
Tom
hat returns a double.
With an include math.h added floortest.pasm is now OK and trans.t
almost passes - it is certainly better than before. There's still
one failure in each of number.t and trans.t though although that
might just be my rather mangled checkout.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
u
updated, so long as you gave it the -d switch.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
ST file, you'll get a
> copy without those empty directories, and the build will fail.
Actually they contain .cvsignore files, but those aren't in the
manifest. Plus you probably don't want them if you're making a copy
based on the manifest that therefore doesn't in
n.
If people think that's a good solution to the problem then I'll have
a go at working up a patch.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:21 PM 10/16/2001 +0100, Tom Hughes wrote:
> >I have a plan to semi-automate it which I nearly implemted the other
> >day but didn't get around to. Basically the idea is to
t. This means that you
> have to explicitly check that you aren't transcoding from an encoding to the
> same encoding.
That is as per Dan's spec. I have thought about adding a wrapper
routine to do the check you refer to.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 17, 2001 at 12:40:36AM +0100, Tom Hughes wrote:
> > I have knocked up a first pass at a patch, which is attached for
> > comments.
>
> I've committed th
e encoding layer to fetch each character and
then the character set layer to determine what digit it represents.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
James Mastros <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Dec 2001, Tom Hughes wrote:
> > It's completely wrong I would have thought - the encoding layer
> > cannot know that a given code point is a digit so it can't possib
else there will doubtless me many
other is_xxx() routines in due course which will be simple boolean
tests.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
In message <[EMAIL PROTECTED]>
Bart Lateur <[EMAIL PROTECTED]> wrote:
> On Thu, 06 Dec 2001 00:16:34 GMT, Tom Hughes wrote:
>
> >So far I have added as is_digit() call to the character type layer
> >to replace the existing isdigit() calls.
>
> T
and
> implementation, however.
Presumably that's G_Floating that you're converting to/from for
the VAX rather than D_Floating?
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <20011210133529.EYKY11472.femail13.sdc1.sfba.home.com@there>
Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
> On Monday 10 December 2001 03:06 am, Tom Hughes wrote:
> > In message <20011210011601$[EMAIL PROTECTED]>
> >
> > Actually VAXes
at arbitrary addresses can be loaded using PC relative loads.
I suspect it is also rather questionable to call system calls
directly rather than going via their C library veneers - that is
even more true when you come to things (like socket calls) which
are system calls on some machines and funct
In message <[EMAIL PROTECTED]>
Daniel Grunblatt <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2001, Tom Hughes wrote:
>
> > I suspect it is also rather questionable to call system calls
> > directly rather than going via their C library veneers - that is
&g
In message <007f01c1930c$9d326220$[EMAIL PROTECTED]>
"Peter Gibbs" <[EMAIL PROTECTED]> wrote:
> Another correction to string_transcode; this function now seems to work okay
> (tested using a dummy 'encode' op added to my local copy of core.ops)
e byte encoding, but probably
not for the unicode encodings due to canonicalisation issues.
> * Add size of string termination to encodings (i.e., how many 0 bytes)
Certainly.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
de typedefs is not a very
good idea, if only because it makes it impossible to const qualify
the pointer without creating a second parallel typedef.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
nning with INT or UINT and ending
with _MAX or _MIN, or macro names beginning with PRI or SCN
followed by any lower case letter or X may be added to the
macros defined in the header.
So struct x_t should be fine because that's a structure tag and
not a type name.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
h is the name of the default encoding for the native character type.
I guess string_init could also set up string_native_encoding by looking
up the name of the default encoding for the native character type.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
rors, rerun with: -v
I haven't attempted to look at this and see what is causing it.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> Syscall param open(pathname) contains uninitialised or unaddressable byte(s)
> at 0x403F1892: __libc_open (__libc_open:31)
> by 0x403829C3: _IO_fopen@@GLIBC_2.1 (iofopen.c:67
some thought though, to determine how best to handle
this issue.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> I have developed patch for this in the form of a new routine
> which returns a nul terminated C style string given a parrot
> string as argument. It does this by making sure buflen is at
>
ys be singlebyte.
You buffer termination code is also wrong - bufused is the end of
the string. You are null terminating the buffer not the string, and
the buffer may have extra space. Plus you have created a buffer
overrun.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
hackers
Which is why I mentioned it a week or two ago ;-)
I also ran it over the test suite and fixed the only bug that it found
at that time...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
can just use the same name in all the libraries
and it won't clash.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
ck, after patch 0.166938s 0.168390s
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
Index: rxstacks.c
===
RCS file: /cvs/public/parrot/rxstacks.c,v
retrieving revision 1.5
diff -u -r1.5 rxstacks.c
--- rxstacks.c 17 Ma
aw in my logic and points out
that the GC will catch it...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
e a contiguous stack - it's
just RISC OS that uses the chunked stack I believe.
I believe you can always tell by looking at where sl points and seeing
if there is a valid chunk descriptor there and then following it's prev
pointer to get the previous chunk if there is one.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
ttp://bugs6.perl.org/rt2/Ticket/Display.html?id=789 >
>
>
>
> stack_chunk is now Stack_Chunk...
Applied. Somebody update the ticket please...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
ttp://bugs6.perl.org/rt2/Ticket/Display.html?id=790 >
>
>
>
> Self-explanatory.
Applied. Somebody please update the ticket...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
ttp://bugs6.perl.org/rt2/Ticket/Display.html?id=788 >
>
>
>
> This patch fixes a number of off-by-one errors in array.pmc, and adds a
> few more tests.
Applied. Somebody please update the ticket...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
he same line, ie:
>
>A: print "a" # prints "a"
> end
>
> then it assembles and runs OK.
Here's a patch that will fix this. I havn't committed it because I'm
not sure why the assember wasn't dropping comments that included quotes
so I&#x
ttp://bugs6.perl.org/rt2/Ticket/Display.html?id=758 >
>
>
>
> Fixes to various of the PASM examples in light of recent changes in the
> assembler.
Applied. Somebody please update the ticket...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <20020713174114$[EMAIL PROTECTED]>
brian wheeler <[EMAIL PROTECTED]> wrote:
> On Sat, 2002-07-13 at 12:32, Tom Hughes wrote:
> > In message <20020703012231$[EMAIL PROTECTED]>
> > Here's a patch that will fix this. I havn't co
nt strings in the byte code are zero terminated
when they aren't, and it is therefore overrunning and printing bits of
the next string or whatever. I have just committed a fix.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
kind of vtable explosion that they promote.
Anyhow, that's probably enough for now... If anybody can elighten me
about how all this is supposed to work then I'll try and knock it all
into shape, starting with making sure that PDD 8 is accurate.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 03:54 PM 7/14/2002 +0100, Tom Hughes wrote:
> >I've been trying to make sense of the current status of keyed access
> >at all levels, from the assembler through the ops to the
r enough. I just took what cvs handed me. It was a fresh checkout as
> of yesterday, updated this morning. Whoever removes those files from the
> repository ought to adjust MANIFEST accordingly.
I have removed the files and updated the MANIFEST to reflect that.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message <[EMAIL PROTECTED]>
"David M. Lloyd" <[EMAIL PROTECTED]> wrote:
> On Sat, 13 Jul 2002, Tom Hughes wrote:
>
> > Of course... The attached patch should handle that I think...
>
> This patch is breaking several Solaris 32-bit test
1 - 100 of 165 matches
Mail list logo
