Re: [PATCH] Cosmetic updates to MD5 library

2005-05-10 Thread Leopold Toetsch
Nick Glencross <[EMAIL PROTECTED]> wrote:

> this patch makes some small updates to the MD5 files.

Thanks, applied.
leo


Re: [PATCH] Cosmetic updates to MD5 library

2005-05-10 Thread Leopold Toetsch
Nick Glencross <[EMAIL PROTECTED]> wrote:

> Still some way off the OS md5sum, which is typically 0.15 seconds, about
> 12x quicker. That may sound quite a bit, but much of it can probably be
> accounted for by inefficiencies in my conversion to parrot code (a
> slightly awkward rol, and perhaps the manipulation of the arrays).

A new opcode C would certainly help, yes. It would replace 4
instructions (each roughly executed once per char) with one instruction.

A JITted C opcode should give a speed up of one forth - which is a
lot.

Another problem is that MD5.imc doesn't process the file blockwise.
md5sum.imc first slurps the whole file into a string then it's converted
to a word array and in a third step it's processed. The influence of
this gets worse with bigger files.

> Contrary to what I keep being told by Java programmers, you'll never
> going to be as fast as optimised C code, let's face it.

There are always some optimizations still.

> Regards,

> Nick

leo


Re: [perl #35365] [PATCH] allow array of args for spawnw

2005-05-10 Thread Leopold Toetsch
Jeff Horwitz <[EMAIL PROTECTED]> wrote:

> the attached patch adds a new signature for spawnw so it can take a PMC
> array of arguments rather than a single string.

Thanks, applied - this one, there was a second mail with a patch.

Please note that patches to platform code need special consideration WRT
other platforms.

Patches to config/gen/platform/generic/ need at least a dummy
implementation in other platforms that don't inherit the generic version
of the platform file. This is in this case additionally:

$ ls config/gen/platform/*/exec.c
config/gen/platform/ansi/exec.c config/gen/platform/win32/exec.c

I've put in an empty stub for both, implementations for win32 are
welcome.

leo


Re: [PATCH] imcc/docs using .pir

2005-05-10 Thread Leopold Toetsch
Dino Morelli <[EMAIL PROTECTED]> wrote:

> I modified some of the .pod files in imcc/docs/ to reflect using .pir
> instead of .imc

Thanks, applied.
leo


[perl #35385] [PATCH] fix dynclasses/ build failure

2005-05-10 Thread via RT
# New Ticket Created by  jerry gay 
# Please include the string:  [perl #35385]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=35385 >


some recent changes have left dynclasses unbuildable on MSWin32 due to
an undefined external linker error.

the attached patch fixes that problem by adding
../src/parrot_config.obj to the list of linked libraries. the same
number of tests fail on win32--msvc-7.1--perl-5.8.6 as before the
patch was applied :)

~jerry


parrot_config.patch
Description: Binary data


Question regarding JIT

2005-05-10 Thread Millsa Erlas
I heard that Parrot has a JIT compiler. If I understand this correctly, 
does this mean Parrot bytecode is converted to native machine hardware 
code before execution? If so, it is a good idea.

JIT is great, however, will it still be possible to run the Parrot 
bytecode on the interpretor?

Also, does the native machine code make calls to the Parrot VM, for 
thinks like storing variables, calling subroutines, and so on? This 
makes sense, since Parrot can still manage memory allocation, and other 
things for the machine code.


[perl #35386] [PATCH] @ANON tests, and some test fixes

2005-05-10 Thread via RT
# New Ticket Created by  jerry gay 
# Please include the string:  [perl #35386]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=35386 >


...at least they're test fixes on win32.

the following patch adds some documentation and tests for the @ANON
subpragma. also, fixes some tests to pass on win32. all expected tests
pass on win32--msvc-7.1--perl-5.8.6.

~jerry


ANON_and_others.patch
Description: Binary data


[perl #35388] [PATCH] building problems

2005-05-10 Thread François
# New Ticket Created by  FranÃois PERRAD 
# Please include the string:  [perl #35388]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=35388 >


This transaction appears to have no content
Two small building problems (r8030)

1) On MinGW, can't execute miniparrot.exe during building
Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your 
fingers
./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
'.' is not recognized as an internal or external command, operable program 
or batch file.

2) 'make hello' fails on linking, because src/parrot_config.o is missing
blib/lib/libparrot.a(global_setup.o)(.text+0x240): In function 
`create_config_hash':
trunk/src/global_setup.c:33: undefined reference to `parrot_get_config_string'

Nota : the target exec_so seems to have the same problem

root_in.patch
Description: Binary data


Re: [perl #35385] [PATCH] fix dynclasses/ build failure

2005-05-10 Thread Leopold Toetsch
Jerry Gay <[EMAIL PROTECTED]> wrote:

> some recent changes have left dynclasses unbuildable on MSWin32 due to
> an undefined external linker error.

Thanks, applied.
leo


Re: Question regarding JIT

2005-05-10 Thread Leopold Toetsch
Millsa Erlas <[EMAIL PROTECTED]> wrote:
> I heard that Parrot has a JIT compiler. If I understand this correctly,
> does this mean Parrot bytecode is converted to native machine hardware
> code before execution? If so, it is a good idea.

Yes, if the platform has the necessary code at least.

> JIT is great, however, will it still be possible to run the Parrot
> bytecode on the interpretor?

Sure. Parrot has multiple different run loops, JIT ableit not being a
real loop is just one of them.

> Also, does the native machine code make calls to the Parrot VM, for
> thinks like storing variables, calling subroutines, and so on? This
> makes sense, since Parrot can still manage memory allocation, and other
> things for the machine code.

Yep. Basically all opcodes that aren't available as native JITed
versions are executed in the plain run core.

leo


Re: [perl #35386] [PATCH] @ANON tests, and some test fixes

2005-05-10 Thread Leopold Toetsch
Jerry Gay <[EMAIL PROTECTED]> wrote:
> ...at least they're test fixes on win32.

> the following patch adds some documentation and tests for the @ANON
> subpragma. also, fixes some tests to pass on win32. all expected tests
> pass on win32--msvc-7.1--perl-5.8.6.

Thanks, applied.
leo


Re: [perl #35388] [PATCH] building problems

2005-05-10 Thread Leopold Toetsch
François" PERRAD <[EMAIL PROTECTED]> wrote:
> Two small building problems (r8030)

> 1) On MinGW, can't execute miniparrot.exe during building
> Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your
> fingers
> ./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
> '.' is not recognized as an internal or external command, operable program
> or batch file.

Why did that work with parrot before my changes? It has the same slash.

> 2) 'make hello' fails on linking, because src/parrot_config.o is missing

Ah, yep missed that, thanks.

> Nota : the target exec_so seems to have the same problem

I've added parrot_config$(O) there too - untested.

Thanks, applied.
leo


Tags

2005-05-10 Thread nickg
Guys,

Does it seem reasonable to clean up some of the tagged versions in the depot 
which have served their purpose? I would suggest:

Remove:
file_move_031023
help
V1? (or rename to something more meaningful?)

Rename:
REL_0_0_5 -> RELEASE_0_0_5

(These tags would continue to be accessible by visiting revisions before the 
cleanup)

Obviously I don't want to upset anyone to whom these tags are precious...

Regards,

Nick



[perl #35391] [TODO] filepath manipulations

2005-05-10 Thread via RT
# New Ticket Created by  Leopold Toetsch 
# Please include the string:  [perl #35391]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=35391 >


During changes related to #34994 I did introduce 3 const cast warnings, 
which are just symptoms of a deeper problem (besides that I'm never 
sure, what should be const and what not;).

We have e.g:

opcode load_bytecode (in STR)

   STRING $1   => char *file

...
Parrot_locate_runtime_file( ... char *file_name)

   STRING *runtime_prefix  => char *prefix
   concat(prefix, file_name) which needs malloc
   char *full_name =>  STRING *str

Parrot_stat_info_intval( ... STRING *file)

 => char *filenamestat(2)

Well, doesn't look really like an overview, but we have several 
string_to_cstring() and string_from_cstring() calls plus 
mem_sys_allocate and strcat.

It was already discussed some time ago that we should have some 
interface functions for this, which would also get rid of the mess 
above. See also "The Perl 6 Summary for the week ending 20030907"
or google for "Path::Class parrot".

As a starter an equivalent of File::Spec::catfile() would suffice to be 
able to rewrite above code.

Comments and proposals welcome,
leo



[PROPOSAL] call syntax abstraction

2005-05-10 Thread Leopold Toetsch
Second attempt and cc'ed to other Perl lists too.
 Original Message 
Subject: [PROPOSAL] call syntax abstraction
Date: Tue, 03 May 2005 13:58:14 +0200
Comments welcome,
leo
=head1 TITLE

Calling convention abstraction

=head1 ABSTRACT

The current Parrot calling conventions as described in
F are not covering major
parts of our target languages. The scheme isn't extensible and uses a
lot of resources (opcodes, runloop dispatches, registers) to achieve
it's work.

This proposal describes an abstract, extensible, and more efficient
alternative to pdd03.

=head1 DESCRIPTIOON

All the work related to function calls is done by dedicated opcodes.
No registers are reserved currently, but during the transition phase
and possibly thereafter, registers are/may be used. This will be
specified after the implementation of the compatibly scheme is
completed.

=head2 Opcodes

New B opcodes:

  op args(inconst STR, ...)# call arguments
  op results(inconst STR, ...) # get return results
  op params(inconst STR, ...)  # function parameters
  op returns(inconst STR, ...) # function return
  op yields(inconst STR, ...)  # coroutine yield values

The constant STR argument is a signature string denoting successional
arguments to the opcode.

An opcode to define return context:

  op results(inconst INT)  # define return context

And:

  op argcI(out INT)# amount of I args or returns
  op argcP(out INT)# amount of P
  op argcS(out INT)# amount of S
  op argcN(out INT)# amount of N

=head2 Call opcodes cleanup

While it's not strictly needed it's highly desirable to get rid of the
current implicit register usage in call related opcodes.

See also: I for an older discussion on that topic.

  op invoke(in PMC, in PMC)# $1 = sub/method, $2 = continuation
  op invoke(in STR, in PMC)# invocants are covered by args

  op invokecc(in PMC)  # $1 = sub/meth, create continuation [1]
  op invokecc(in STR)  # invocants are covered by args

  op tailcall(in PMC)  # $1 = sub/method
  op tailcall(in STR)

[1] if the called thing isa NCI PMC the creation of the continuation
is skipped.

=head2 Signature chars - current calling scheme coverage

  I... INTVAL var
  i... INTVAL constant
  N,n,S,s,P,p   ... analog
  O... single PMC invocant
  @... call: flatten array to next args

=head2 Signature chars - possible extensions

  @... call: flatten
   params/results: make array
  %... call: flatten **kw hash
   params(/results): make hash
  kX   ... call: named arguments (key => X)
  OO   ... call: 2 PMC invocants
  :... call: end of invocants marker
  nX   ... params: default arguments (name = X)
  ?... params: optional part follows
  =P   ... params/returns: clone P  (or maybe cP)
  &... ruby code block

E.g.

  args "PP", P10, P20   # function call
  args "OIS", P5, I10, S30  # method call
  args "P:IS", P5, I10, S30 # same method call
  args "P@", P0, P1 # flatten P1, args become P0, *P1
  args "%", P2  # P2 is a **kw hash
  args "kPkP", "$a", P0, "$b", P1   # named arguments "$a" => P0, ...
  params "ni", "$i", 1  # default argument "$i" = 1
  params "P?PPP"# await 1 - 4 arguments passed in

=head2 Return context

  results 0  # void
  results 1  # 1 return result
  results n  # n return result
  results -1 # list context

As the I opcode goes before the call, we can attach a perlish
return context to the return continuation and make it available in the
called function.

=head2 Simple example

  .sub main @MAIN
args "IN", I16, N16[1]
invokecc "foo" [2]
results "I", I16   [3]
  .end

  .sub "foo"
 params "IN", I16, N16 [4]
 ...
 returns "I", 1[5]
  .end

=head2 Comparison with current syntax

  .sub main @MAIN
set I0, 1  [1]
set I1, 1
set I2, 0
set I3, 0
set I4, 1
set I5, I16
set N5, N16
set S1, "IN"
invokecc "foo" [2]
set I16, I5[3]
  .end

  .sub "foo"
set I16, I5[4}
set N16, N5
...
set I0, 1  [5]
set I1, 1
set I2, 0
set I3, 0
set I4, 0
set I5, 1
returncc
  .end

=head2 opcode and dispatch count comparison

  current scheme proposed scheme
  opcodes call/result   29  9
  dispatches10  3

  opcodes param/ret 25  7
  dispatches 9  2

  opcodes overall   54 16
  dispatches19  5

=head2 Example main

  .sub main @MAIN

params "@", P5# argv array like now
params

Re: Tags

2005-05-10 Thread Leopold Toetsch
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Guys,

> Does it seem reasonable to clean up some of the tagged versions in the depot 
> which have served their purpose? I would suggest:

> Remove:
> file_move_031023
> help
> V1? (or rename to something more meaningful?)

I've no clue what these tags are denoting but maybe they are of some
historical interest.

> Rename:
> REL_0_0_5 -> RELEASE_0_0_5

Rename sounds reasonable.

> Regards,

> Nick


leo


Re: [PATCH] imcc/docs using .pir

2005-05-10 Thread Dino Morelli
On Tue, 10 May 2005, Leopold Toetsch wrote:

>Dino Morelli <[EMAIL PROTECTED]> wrote:
>
>> I modified some of the .pod files in imcc/docs/ to reflect using .pir
>> instead of .imc
>
>Thanks, applied.
>leo

Thank you, leo.


Some of these .pod files are used by the website, down in
http://www.parrotcode.org/docs/imcc

Should I change anything else to make the new documents used by the
site? At the moment, they don't match.

-Dino

-- 
 .~.Dino Morelli
 /V\email: [EMAIL PROTECTED]
/( )\   weblog: http://categorically.net/d/blog/
^^-^^   preferred distro: Debian GNU/Linux  http://www.debian.org


Re: [PATCH] Cosmetic updates to MD5 library

2005-05-10 Thread Leopold Toetsch
Leopold Toetsch wrote:
Nick Glencross <[EMAIL PROTECTED]> wrote:

Still some way off the OS md5sum, which is typically 0.15 seconds, about
12x quicker. That may sound quite a bit, but much of it can probably be
accounted for by inefficiencies in my conversion to parrot code (a
slightly awkward rol, and perhaps the manipulation of the arrays).

A new opcode C would certainly help, yes. It would replace 4
instructions (each roughly executed once per char) with one instruction.
A JITted C opcode should give a speed up of one forth - which is a
lot.
I was a bit too optimistic with my assumptions here. I have now 
implemented a C opcode and the one used signature for MD5 as a JIT 
opcode for x86. But the speedup is much smaller: around 5%.

md5sum of perl-5.8.0.tar.gz  size=11023084
md5sum 0.11 user,  0.20 real
parrot -j  2.63 user   2.68 real
parrot -j rot  2.57 user   2.75 real
The problem with md5 code and Parrot JIT seems to be related to the 
register allocator. md5 code is one big basic block of integer code. As 
we don't do any register renaming, the CPU-register usage especially on 
x86 is suboptimal.

leo


Re: patch to is_cclass for offset beyond end of string

2005-05-10 Thread Jens Rieks
On Monday 09 May 2005 07:53, Patrick R. Michaud wrote:
> The attached patch file adjusts C to always return false
> for offsets beyond the end of the string, and updates
> t/op/string_cclass.t to test this.
Thanks, applied!

find_cclass and find_not_cclass are in now.

jens


[perl #35393] [PATCH] _config cleanup

2005-05-10 Thread via RT
# New Ticket Created by  jerry gay 
# Please include the string:  [perl #35393]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=35393 >


the new *_config$(O) files are not cleaned up during make
clean/realclean... until now. 'svn status' reports these files have
been removed after 'make clean'

~jerry


Index: config/gen/makefiles/root.in

===

--- config/gen/makefiles/root.in(revision 8041)

+++ config/gen/makefiles/root.in(working copy)

@@ -1281,6 +1281,9 @@

 $(SRC_DIR)/pbc_info$(O) $(PINFO) \
 $(PDB) $(SRC_DIR)/pdb$(O) \
 $(DIS) $(SRC_DIR)/disassemble$(O) \
+   $(SRC_DIR)/null_config$(O) \
+   $(SRC_DIR)/parrot_config$(O) \
+   $(SRC_DIR)/install_config$(O) \
 $(LIBNCI_TEST_SO) \
 $(LIBPARROT)
$(PERL) build_tools/c2str.pl --init


[perl #35392] Question about Parrot

2005-05-10 Thread Leopold Toetsch via RT
> [EMAIL PROTECTED] - Tue May 10 06:00:52 2005]:

[cc'ed to our list, ticket #35392 ]

> Dear Perl eating Parrots,
> 
> I hope you are the appropriate person to send this email to.

Almost :) Please use perl6-internals@perl.org for replies or questions
about parrot.

> Will Perl 6 have a tracing API or will it rely on a tracing API in 
> Parrot?

It'll provide some interface and rely on Parrot.

> Will Parrot have a tracing API?

For sure, but this isn't speced yet. But parrot can already run with a
--trace (-t) option, which produce an opcode trace.

> Ideally a tracing API would provide the following:
> o Trace enter/exit of functions
> o Trace line visits
> o Trace exception events
> o Provide access to function parameters
> o Provide access to function return value(s) (for languages that support 
> multiple return values).
> o Provide access to local variables

I'm pretty sure that we will cover all...

> o Memory/Object allocation
> o Memory/Object reallocation
> o Memory/Object moved (used by GC)
> o Memory/Object deallocation (during GC or explcitly by language 
> extension).
> o Garbage collect start
> o Garbage collect end

... including GC and memory stats, which are already supported.

> In addition to the above the tracing API would be well served by 
> including the following multi-threading events (which are absent from 
> Python/Ruby tracing and possibly absent from Lua/Tcl tracing).
> 
> o Enter/Entered/exit monitor/synchronization event so that you can track 
> which locks are pending acquisition/locked/released.
> o Starting Wait/Finished Wait

I can't say much about these, as the thread models aren't really fully
implemented.

> I suppose an alternative would be an instrumentation API which would 
> allow tool vendors to instrument the byte code. Java and .Net provide 
> these - they also provide all of the above mentioned items (including 
> the multi-threading and memory events).

Yep. instrumenting bytecode is for sure doable.

> I work for Object Media Limited. We implement software tools which are 
> marketed by Software Verification. We provide Software Tools for 
> Coverage, Performance, Flow Tracing and Thread Analysis for Python and 
> Ruby. We will soon be extending this to include Memory Analysis tools 
> for Python and Ruby.
> 
> Software Verification's website is http://www.softwareverify.com
> 
> We would like to support Perl 6/Parrot when it is possible to do so.
> 
> Regards
> 
> Stephen
> [EMAIL PROTECTED]

leo


embedding/extending interface

2005-05-10 Thread Jeff Horwitz
as part of both the pugs and mod_parrot effort, i've started working on
bringing the embedding and extending interfaces into the modern parrot
era.  i'd like to start by adding public APIs (Parrot_*) where necessary
and adding missing prototypes to the headers.  this will clean things up
without changing any of the working parts.

is there anyone else besides myself and autrijus who is actively working
on an embedded parrot application?

-jeff




Re: patch to is_cclass for offset beyond end of string

2005-05-10 Thread Jens Rieks
On Tuesday 10 May 2005 20:29, Patrick R. Michaud wrote:
> On Tue, May 10, 2005 at 05:08:49PM +0200, Jens Rieks wrote:
> > On Monday 09 May 2005 07:53, Patrick R. Michaud wrote:
> > > The attached patch file adjusts C to always return false
> > > for offsets beyond the end of the string, and updates
> > > t/op/string_cclass.t to test this.
> >
> > Thanks, applied!
> >
> > find_cclass and find_not_cclass are in now.
>
> This is *excellent*.
>
> However, now that I look at things, I'm wondering if a slight
> change to the specification would be in order -- in my original
> post I said that find_cclass and find_not_cclass would return -1
> whenever they (didn't find | found) the character of interest --
> perhaps it would be better for them to return the length of
> the string instead?
>
> This might make it easier to do things like:
>
> .local int pos
> .local string token
>
> $I0 = find_not_cclass .CCLASS_WORD, $S0, pos
> $I0 -= pos
> token = $S0
>
> whereas if we return -1 on "not found", we have to do some funny
> checking for it (rather than getting a nice null string).
> Note that we can still easily check for the existence of the char...
>
> .local int pos
> .local string token
>
> $I2 = length $S0
> $I0 = find_not_cclass .CCLASS_WORD, $S0, pos
> if $I0 == $I2 goto end_of_string_reached
>
> If you're in agreement, I'll create/submit a patch and update
> the test files.  Best to decide this now before too many people
> start using it.  :-)
Yes, sounds reasonable.

> Pm
jens


Question about Parrot and Omniscient Debugging

2005-05-10 Thread Andy_Bach
Hi,

Please excuse the possible 'out of left field' (as we say) aspect of this 
question but I recently heard about Omniscient Debugging (ODB):
http://www.lambdacs.com/debugger/debugger.html

There is an article in the latest Dr Dobbs (6/05) by the above fellow (Bil 
Lewis - former Sun scientist and author of the GNU Emacs Lisp manual)- 
he's got a java implementation of ODB.  Basically every change to every 
obj/var is tracked, so you can work back through the whole run in one try, 
w/o the 'set breakpoint/rerun' sort of iterativeness that goes on, 
normally.  His story is that the JVM is esp. suited to doing this, making 
the ODB quite easy, so I asked him about how to go about this for 
perl/p6/parrot:

"I took a peek at Parrot... It didn't say the "right" things about how
a VM should work, which worries me.

In any case, all you have to do is to have your code make the appropriate
calls into my recording functions everytime the appropriate event occurs.
I do this in Java with byte code insertion. Looks like this will be much
harder in the Parrot VM, but still possible.

It could be easier to do in the compiler, if you're good with compilers."

[ I asked what were the 'right things' ]

"The JVM, CLR, and ELisp are all stack machines and they work *really*
well. And being a stack machine makes a lot of stuff *really* easy to do.
As opposed to previous experience with VMs done as flat register machines.
Which have proven harder to work with.

Parrot tosses that out and fails to give a convincing argument why.
They talk about Perl being interpreted as important. It isn't. You
shouldn't even know what it's doing at that level."

I don't mean to quote him out of context or to start a stack vs register 
debate, I was just hoping to get some idea from him what is needed to get 
ODB to work, but didn't know if there was any hope for it in p6.  The 
lambdaCS site has the java jar/source and a nice enough demo of his 
implementation, there are a couple of commercial apps:
http://www.omnicore.com/registercodeguide.jsp
http://www.visicomp.com/

both of which seem to be java only.  It would seem to be a very useful 
addition to the world of perl debugging, if it could be shoehorned in w/o 
a horrible amount of work. However, I'm not the person to do the 
shoehorning.

Thanks.


Andy Bach, Sys. Mangler
Internet: [EMAIL PROTECTED] 
VOICE: (608) 261-5738  FAX 264-5932

"Outside of a dog, a book is man's best friend. Inside of a dog, its too 
dark to read."
Groucho Marx


Re: patch to is_cclass for offset beyond end of string

2005-05-10 Thread Patrick R. Michaud
On Tue, May 10, 2005 at 05:08:49PM +0200, Jens Rieks wrote:
> On Monday 09 May 2005 07:53, Patrick R. Michaud wrote:
> > The attached patch file adjusts C to always return false
> > for offsets beyond the end of the string, and updates
> > t/op/string_cclass.t to test this.
> Thanks, applied!
> 
> find_cclass and find_not_cclass are in now.

This is *excellent*.

However, now that I look at things, I'm wondering if a slight
change to the specification would be in order -- in my original
post I said that find_cclass and find_not_cclass would return -1
whenever they (didn't find | found) the character of interest --
perhaps it would be better for them to return the length of
the string instead?

This might make it easier to do things like:

.local int pos
.local string token

$I0 = find_not_cclass .CCLASS_WORD, $S0, pos
$I0 -= pos
token = $S0

whereas if we return -1 on "not found", we have to do some funny
checking for it (rather than getting a nice null string).
Note that we can still easily check for the existence of the char...

.local int pos
.local string token

$I2 = length $S0
$I0 = find_not_cclass .CCLASS_WORD, $S0, pos
if $I0 == $I2 goto end_of_string_reached

If you're in agreement, I'll create/submit a patch and update
the test files.  Best to decide this now before too many people
start using it.  :-)

Pm


Re: Question about Parrot and Omniscient Debugging

2005-05-10 Thread Autrijus Tang
On Tue, May 10, 2005 at 11:11:12AM -0500, [EMAIL PROTECTED] wrote:
> Please excuse the possible 'out of left field' (as we say) aspect of this 
> question but I recently heard about Omniscient Debugging (ODB):
> http://www.lambdacs.com/debugger/debugger.html

This seems to require almost the same journaling capacity for STM
(software transactional memory), although in STM's case we only mark
updates for "shared" variables, whilst in ODB a journal is kept for all
updates.

It is conceivable to build this facility into the PMCs, much like
how tied objects work, but my knowledge of parrot internals is
insufficient to answer whether it will be difficult or not.

Adding this sort of instrumentation is, however, much easier from a
compiler's point of view; all you need to do is to generate extra
instructions that records the timestamp, the variable being updated,
and its original value.  It will require a recompilation, and the
result is difficult to share across different Parrot-targetting
languages, so it's the less optimal choice.

If you'd like to experiment with adding such instrumentation to Perl 6
(and history navigator, etc), I can give you a committer bit in Pugs --
you can do logged PMCs in the form of IVars, or by generating more
instructions in the AST evaluation layer.  The latter approach can be
reused in the Parrot code generator, too.

Thanks,
/Autrijus/


pgpEf7sSgfBiX.pgp
Description: PGP signature


Re: r7994: win32--msvc-7.1--perl-5.8.6 test error report

2005-05-10 Thread François PERRAD
At 13:55 06/05/2005 -0700, you wrote:
t\op\debuginfo.t  5  1280 85  62.50%  4-8
Consider the last version of my patch attached to [perl #35083].
Francois.
~jerry


debuginfo.patch
Description: Binary data


Re: [perl #35388] [PATCH] building problems

2005-05-10 Thread François PERRAD
At 09:43 10/05/2005 +, you wrote:
> 1) On MinGW, can't execute miniparrot.exe during building
> Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your
> fingers
> ./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
> '.' is not recognized as an internal or external command, operable program
> or batch file.
Why did that work with parrot before my changes? It has the same slash.
Not the same with MinGW (eg. GNU make + gcc on Win32)
Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your 
fingers
.\miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
If the next line prints 0.2.0-devel, it did help.
.\miniparrot.exe parrot-config.imc VERSION DEVEL

See Parrot_Exec_OS_Command (http://xrl.us/fimc) and [perl #34605].
Francois.
leo


Re: Question about Parrot and Omniscient Debugging

2005-05-10 Thread Leopold Toetsch
Autrijus Tang wrote:
On Tue, May 10, 2005 at 11:11:12AM -0500, [EMAIL PROTECTED] wrote:
Please excuse the possible 'out of left field' (as we say) aspect of this 
question but I recently heard about Omniscient Debugging (ODB):
http://www.lambdacs.com/debugger/debugger.html
Sounds very powerful
This seems to require almost the same journaling capacity for STM
(software transactional memory), although in STM's case we only mark
updates for "shared" variables, whilst in ODB a journal is kept for all
updates.
Yep
It is conceivable to build this facility into the PMCs, much like
how tied objects work, but my knowledge of parrot internals is
insufficient to answer whether it will be difficult or not.
I've already described in my summary http://xrl.us/f234 2.2) that we 
should split the vtable into various parts[1]. We should be able to 
switch to a read-only variant of a PMC for example.
Switching in some vtable pieces that logs set_*_* vtable calls is more 
or less the same thing.

vtable.tbl already has most of this information: see "[STORE]". There is 
an experimental feature 'pmclass SArray const_too' in the SArray PMC, 
where two vtables are created, switchable by setting the "_ro" property.

But this is all really rough and not a general solution.
See also "Layering PMCs" http://xrl.us/f236 for an older discussion 
about vtables and "roles" and "VTABLE methods and interfaces" 
http://xrl.us/f237.

[1] The vtable is currently almost 600 bytes (32bit system). By 
switching full vtables just to get a read-only variant, we'd need a lot 
of memory. And: a scalar PMC doesn't need nor implement the array-ish 
vtable slots. I prefer one more indirection for almost all of the vtable 
slots.

leo