require 4 charsets.
The problem is that there are hundreds of characters sets that
use a single byte encoding so you're going to wind up duplicating
the encoding related actions for all those character sets.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
-level keys, but that
doesn't actually seem to be the case. I can only assume that the
original reason was to support multi-level keys though.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
it
in a while...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
of space that would be
needed to avoid truncation if the result is truncated.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
);
}
internal_exception(OUT_OF_BOUNDS,
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
type.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
to solve the problem. Applied.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
---
t/pmc/intlist.t2 512 42 50.00% 3-4
Failed 1/1 test scripts, 0.00% okay. 2/4 subtests failed, 50.00% okay.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
In message lists.perl6.internals/[EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
Tom Hughes wrote:
Unfortunately it doesn't test clean afterwards:
dunsmere [~/src/parrot] % perl t/harness t/pmc/intlist.t
t/pmc/intlistNOK 3# Failed test (t/pmc/intlist.t at line
Configure.pl ad infinitum.
I'm not quite sure how to resolve this in the long term as there are
conflicting goals here, but I've committed the patch for now.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
and anyop.c in languages/imcc as they are not built, and seem to have
been removed from the MANIFEST but are still in the repository.
Are these now dead? If they are then I'll remove them, otherwise they
need to go back into the manifest.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
it with a value of 0 to reset the intlist?
I suspect that it might be better to have a separate intlist_reset or
intlist_empty or something to do that rather than a wierd boolean
parameter like that. Not a major issue though.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
In message [EMAIL PROTECTED]
Andy Dougherty [EMAIL PROTECTED] wrote:
On 26 Sep 2002, Tom Hughes wrote:
The problem here is that the rule in the Makefile that causes it to
rerun Configure.pl if any of the Configure.pl generated files is out
of date clashes with the recently
and therefore probably shouldn't be ;-)
Seriously, I'd suggest putting the common code into intlist_new_chunk
or something and then have intlist_new call that before doing the
other setup. That way you don't need the extra argument.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
issues. I don't really understand what you mean by the
third one so I can't comment much on that...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
to look at the detailed implementation of Sun's qsort to say for sure.)
Here's the patch that fixes it.
Applied.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
not to?
I believe you could encode a key constant with zero components in the
byte code if you wanted - the first word of the constant is the
component count after all.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
operands, gives you 64 ops in total.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
Tom Hughes wrote:
You will still get horrible op explosion for a three argument op as
even if you assume that all PMCs are keyed, there are four key types
which, with three operands, gives you 64 ops in total
, but if many operations will be on lexicals as
opposed to registers/temporaries, such hoariness might be worth it.
Except those indexes are key constants which are type kc but Leopold
only wants to allow dynamically created keys of type k on the other ops.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http
the optimised _int vtable methods for keyed
access using integer keys...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
that a const method can change any
mutable members of the object ;-)
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
In message [EMAIL PROTECTED]
Tom Hughes [EMAIL PROTECTED] wrote:
That explains why you are not seeing the last component. You are also
missing the first one for some reason. The most likely cause would be
that you have already used key_next to discard the first component
before you
can be used to fetch
and set the value of elements in the list.
Does anybody have any objections to this, or any better ideas on how
to handle this?
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
of elements in a key it is manipulating?
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
. Being a
non-english speaker, I may be wrong, but then we are to put all verbs to the
third person for consistency...
Your grasp of english grammar is certainly better than my grasp of
french grammar ;-)
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
.
Not that that is necessarily a reason not to commit it, but I just
thought I'd point it out.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
In message 20020825155505$[EMAIL PROTECTED]
Tom Hughes (via RT) [EMAIL PROTECTED] wrote:
Recent changes to imcc make it require a working Parrot_dlopen but
unfortunately as things stand it never does work because Configure.pl
never sets HAS_DLOPEN so Parrot_dlopen is also stubbed
makefile - the main
parrot makefile only links against libdl if Configure.pl discovers
that perl5 does.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
to rearrange itself if it gets too
full.
What the BASIC interpreter probably needs to do is stringify those
keys itself before trying to look them up.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
? basic.pbc
? merged_basic.pasm
Index: basicvar.pasm
===
RCS file: /cvs/public/parrot/languages/BASIC/basicvar.pasm,v
retrieving revision 1.10
diff -u -r1.10 basicvar.pasm
--- basicvar.pasm 20 Jun 2002 00:05:09 - 1.10
+++
to date, and as everybody seems to
be happy with it I'm going to go ahead and commit it now.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
the data directly to the cache and do away with key atoms
completely... I shall get on with that now and post a new patch later.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
get_integer on a Key PMC will work when
the key is a string or it won't.
In fact there isn't a Hash class at the moment, only a PerlHash.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
the 5.2'th element of an array...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
- it was converting them to strings and then looking
them up in the normal way.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
will handle the type conversion
issues when necessary.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
-keyed.
That whole if/else is being reordered as well ;-)
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
Does anybody know the _keyed_int PMC methods take the key as a pointer
to an INTVAL instead of a straight INTVAL?
It doesn't seem to make any sense so unless somebody knows of a reason
for it I plan to change it as part of my keyed access patch...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http
In message [EMAIL PROTECTED]
Tom Hughes [EMAIL PROTECTED] wrote:
Does anybody know the _keyed_int PMC methods take the key as a pointer
to an INTVAL instead of a straight INTVAL?
It doesn't seem to make any sense so unless somebody knows of a reason
for it I plan to change
In message a05111b5bb9786eae041d@[63.120.19.221]
Dan Sugalski [EMAIL PROTECTED] wrote:
At 6:58 PM +0100 8/8/02, Tom Hughes wrote:
Presumably with all keys being PMCs we will just encode the key
arguments in the opcode name as a k, and kc for constant keys.
Yep.
Likewise
the access.
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 tests. The following
assembly (from t/pmc/perlarray1.pbc
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/
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 vtables and
it has to be said
/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/
/Display.html?id=790
Self-explanatory.
Applied. Somebody please update the ticket...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
/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/
havn't committed it because I'm
not sure why the assember wasn't dropping comments that included quotes
so I'm giving people who know more about the assembler than me a chance
to comment first...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
Index: assemble.pl
/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 committed it because I'm
not sure why the assember wasn't
,
3 end
This is a bug in the debugger (and also in the opcode tracing) where
it is assuming that constant 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
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/
it...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
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 May 2002 21:38:20
and it won't clash.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
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/
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/
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
least one greater than bufused
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)
by 0x809B287: cg_core
this issue.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
.
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/
if it were C++ and we
were using a smart pointer class I don't mind the practice.
I will agreee that hiding pointers inside 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
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)
Applied, thanks.
Tom
--
Tom Hughes ([EMAIL
bytes)
Certainly.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
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
even more true when you come to things
?
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 have perfectly ordinary endianness - it was PDPs
, of
course, can't be used for not-a-digit, since is_digit('0')==0.
I was assuming there would a separate digit_value() routine to avoid
that problem. Apart from anything else there will doubtless me many
other is_xxx() routines in due course which will be simple boolean
tests.
Tom
--
Tom Hughes ([EMAIL
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 possibly
do string to number conversion.
You
and
then the character set layer to determine what digit it represents.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
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/
and change
string_length into a direct fetch.
As far as I know the strlen member should always be correct. I was
certainly trying to make sure it was because strings.pod explictly
says that it will be and that it can be used directly instead of
calling string_length().
Tom
--
Tom Hughes ([EMAIL
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/
to have it on we should as it will
impact performance.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
object files from all the current
subdirectories rather then just one, and have committed it.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
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
;-) Doubtless a similar effect would be seen
though.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
about basename clashes then we can always
move all the ops files into an ops subdirectory.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
: 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/
so I haven't tried that as yet.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
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 when we have support
for that.
Could
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 is my first pass at this - it's not fully ready yet but
is something
In message [EMAIL PROTECTED]
James Mastros [EMAIL PROTECTED] wrote:
On Mon, Oct 29, 2001 at 11:20:47PM +, Tom Hughes wrote:
I suspect that the encode and decode methods in the encoding vtable
are enough for doing chr/ord aren't they?
Hmm... come to think of it, yes. chr
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]
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 spend lots of
time going down the wrong path
both translations and we will have effective duplication.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
of the comparison ops exist...
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 fully ready yet but
is something
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 else spots, let me just add what I
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
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/
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/
that was what strings.pod was...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
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
--
Tom Hughes ([EMAIL PROTECTED])
http
`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 warnings.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
Index: packfile.c
* 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
diff -u -r1.8
1 - 100 of 131 matches
Mail list logo
