Probably not. I was merely trying to save an RFE I saw in one of leo's mails.
If it looks like it's there, feel free to close the ticket.
chromatic wrote:
On Sun, 2005-06-12 at 07:27 -0700, Will Coleda wrote:
BTW: a nice to have: include SVN revision of local copy in bug report.
It looks
Verified, still borked in r8328
William Coleda wrote:
With a fairly recent parrot (8308)
oolong:~/research/parrot/languages/m4 coke$ make
cc -g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe
-fno-common -Wno-long-double -I../../include -g -Wall
-Wstrict-prototypes -Wmissing
With a fairly recent parrot (8308)
oolong:~/research/parrot/languages/m4 coke$ make
cc -g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common
-Wno-long-double -I../../include -g -Wall -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-al
I've:
- opened tickets for 0.2.2 and 0.2.3,
- moved any child tickets that are children of the tickets for 0.1.3, 0.1.4,
0.2.0 tickets to the 0.2.2 release (nine altogether).
- resolved the old release tickets.
Chip -
Check out https://rt.perl.org/rt3/Ticket/Display.html?id=36256 and obvi
This ticket was updated to reflect that both scheme and Tcl still used Perl*
pmcs.
Attached is a patch for scheme that removes the Perl* from it.
FYI, the following two tests fail before and after my patch. (Updated
LANGUAGES.STATUS to reflect this.)
Failed Test Stat Wstat Total
open currently returns an Undef PMC if it fails to open a file. Should it
instead return a None? Or, IMO, a Null?
Someone should probably do a cleanup in the core on None vs. Undef vs. Null to
insure they are used consistently and appropriately.
FWIW, it also seems unfair (or at least, unobvio
Is it possible to do substitutions with PGE yet? If so, how?
From languages/LANGUAGES.STATUS:
N: bc
A: Bernhard Schmalhofer
D: Needs antlr and Python
S: Not working and not yet in Parrot SVN
M: Yes
V: 0.1.2
Ron Blaschke wrote:
I'm feeling rather dumb asking this, but F says:
Currently GNU bc is only used for doublechecking Parrot bc.
Now, my quest
Note:
Any tickets which list "will-parrotodo ..." as the requestor don't need to have
replies sent back to the requester - they are placeholders generated from now long gone
TODO files. Followup probably should go to the list, though.
And, "chip claimed a ticket???!?"
* gets the vapors.
Chip
Looking through the PGE test examples, it *looks* like subrules are just globals. (so, if I
refer to in a rule, there should be a Match object in a global named
"frob")
e.g., from the PIR code generated for the phone test:
name = "digits"
subpat = "\\d+"
rul
Making some modifications to the tcl PIR, I just got the following error:
(cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc
languages/tcl/lib/tcllib.imc)
make: *** [lib/tcllib.pbc] Error 138
running through gdb, I see:
(gdb) run languages/tcl/lib/tcllib.imc
Starting program: /Users/
With this patch, Tcl is now failing the same two tests for me that it's been failing for leo:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/cmd_break.t 1 256 21 50.00% 2
t/cmd_con
Done. Thanks!
William Coleda wrote:
Cool. This means I don't have to do a lookup everytime I want to use one
of my own types (per type per sub). Tcl will be patched shortly to take
advantage.
Leopold Toetsch wrote:
The first steps for HLL language and type support are in. You ca
Cool. This means I don't have to do a lookup everytime I want to use one of my
own types (per type per sub). Tcl will be patched shortly to take advantage.
Leopold Toetsch wrote:
The first steps for HLL language and type support are in. You can now
dynamically load a HLL _group PMC library by j
Yeah, the PIR I showed was a bit of a hack based on current functionality. Thinking about it more, I think we do need to have true morphing between TclLists and TclStrings, especially we get to true language interopability.
This is a problem with the current set of vtables, because while I can e
inline (unique to ParTcl), which lets you do:
puts "This is Tcl"
inline PASM {
print "This is PASM\n"
}
as well as some other minor missing tests.
William Coleda wrote:
With Leo's recent fixes to , the following now works:
.sub main @MAIN
load_bytecode "
Because this appears to have been written primarily for perl implementors.
It does the following escapes:
1 \xhh1..2 hex digits
2 \ooo1..3 oct digits
3 \cX control char X
4 \x{h..h}1..8 hex digits
5 \u 4 hex digits
6 \U 8 hex
They certainly can. Tickets can have child tickets, or pre-requisite tickets,
each of which can have its own takers.
The long term planning is the sort of thing that could also go in docs/ROADMAP.
Regards.
Leopold Toetsch wrote:
Yeah. As these are several steps, I'd like to have some takers f
With Leo's recent fixes to , the following now works:
.sub main @MAIN
load_bytecode "languages/tcl/lib/tcllib.pbc"
.local pmc tcl_compiler,compiled_sub
tcl_compiler = compreg "TCL"
compiled_sub = compile tcl_compiler, "puts {ok 1}"
compiled_sub()
.end
Additionally, at Leo's suggestion,
If someone wanted to convert languages/tcl in such a fashion, that would be
cool.
[EMAIL PROTECTED] wrote:
Author: bernhard
Date: Tue May 3 14:32:31 2005
New Revision: 7965
Added:
trunk/languages/m4/src/builtin.pir
- copied, changed from rev 7963, trunk/languages/m4/src/builtin.imc
tr
The garbage collection issues that were stopping ParTcl's test suite (FYI,
*not* Tcl's test suite) from working seem to be gone now!
I've gotten passing reports on all tests (that aren't TODO'd) from OS X,
FreeBSD, and Linux.
ParTcl is part of the parrot svn repository. See:
http://www.parrotcode
Matt Diephouse wrote:
Leopold Toetsch wrote:
classes/pmcarray.pmc wrapper for PerlArray
I'm not sure what was discussed here.
I believe this is a remnant from before it was decided that we'd use "Resizable" and
"Fixed" for container types; Anything that's using PMCArray should be switched t
Per Leo, this is unnecessary, as Perl will be one of the magic dynamic pmcs
that will sneakily load the dynamic library for you if you have yet to do so.
Bernhard Schmalhofer via RT wrote:
[coke - Fr 26. Nov 2004, 16:21:31]:
Like all other language specific PMCs, Perl PMCs should only be loaded
at
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
Still some GC bugs kicking around that neither Leo nor I have been
able to find yet. (Note that the bug in [string] may actually be a PGE
leak, as that code uses the glob rules).
Well there are GC and other bugs, probably.
Ah. That would explain why I had to back in and delete the file that I had
already deleted - because I deleted the wrong file!
Fixed.
Leopold Toetsch wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
--- trunk/MANIFEST (original)
+++ trunk/MANIFEST Tue Apr 19 16:51:10 2005
@@ -50,7 +5
Still some GC bugs kicking around that neither Leo nor I have been able to find
yet. (Note that the bug in [string] may actually be a PGE leak, as that code
uses the glob rules).
Failed TestStat Wstat Total Fail Failed List of Failed
-
There are some potentially crufty tickets out there. Can the relevant experts
verify if these can be closed before we get the next release out?
Win32: (10 tickets)
http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Platform&Value=mswin32
http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Platf
're seeing anything other than this failing, please open an RT
ticket.
Thanks.
William Coleda wrote:
Ok. I was somewhat surprised to hear about the Tcl breakages recently. I
expect that Tcl is going to work on all of Parrot's supported OSen. Here
are some recent improvements.
o fixed the mo
Ok. I was somewhat surprised to hear about the Tcl breakages recently. I
expect that Tcl is going to work on all of Parrot's supported OSen. Here are
some recent improvements.
o fixed the most gratuitous GC errors that Leo diagnosed.
o committed a patch so that PGE is built by default (per chip).
Cool. Can I co-opt this so I can get tcl-like backtraces when running tcl code?
If so, how? =-)
Jens Rieks wrote:
Hi,
the new backtrace code is in. If a parrot program aborts due to an error, a
backtrace is shown. Examples:
Null PMC access in invoke()
current instr.: 'd' pc 149 (t/op/debu
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
The recent conversion to mostly defaulting to ascii has broken Tcl (*again*).
./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl
No, I don't think so.
$ ./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl
He
Matt Diephouse wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
6) avoid using ".local" to mean something different based on context (macro or not)
I'm not sure what you mean.
.local inside a macro is actually a label, not a variable. From the imcc
docs:
---
Macros support
Currently, the following syntax is allowed, and used in examples and code
throughout the repository:
.local String foo
foo = new String
.sym String bar
bar = new String
But... this isn't actually enforced. You can do:
.local String foo
foo = new Blorp
Basically, anything that isn't one of the ba
Or, rather, find the attached patch here:
https://rt.perl.org/rt3/Ticket/Attachment/110536/75860/dynamic_perl2.patch
(whoops)
William Coleda wrote:
Attached find the second patch in the "make perl dynamic" series. This
attacks most of the simplistic cases under t/*.
Many instances of
There are two open tickets about removing the core's dependance on Perl* PMCs,
and instead, making them dynamically loadable and using the language agnostic
PMCs for internal use.
Talking about this with Leo on IRC, he expressed an interest in getting these
changes in chunks to make them a littl
I've been trying to add unicode support into Tcl... adding the parser support
worked fine, so that I was able (in my sandbox) to get:
puts \u30b3\u30fc\u30d2\u30fc
Working... because puts is just iso-8859-01, and the unicode was just unicode.
Once I started trying to do mix and match, I started g
As far as I know, no one is working on these at the moment.
Volunteers welcome, of course. ^_^
[EMAIL PROTECTED] wrote:
hi,all
have a Php compiler to parrot project?
have a ruby compiler to parrot project?
(whoops)
I just added octal and hex escapes to my local copy of the Tcl parser. I was
working on unicode when I noticed that not all of the transcodes are done yet.
This works:
$S0 = unicode:""
$S1 = chr 0x30b3
$S0 .= $S1
print $S0
print "\n"
This does not:
$S0 = ascii:""
$S1 = chr 0x30b3
I just added octal and hex escapes to my local copy of the Tcl parser. I
was working on unicode when I noticed that not all of the transcodes are done
yet.
This works:
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
When invoking a PIR-defined object from C, what's the proper call?
pmc_new ? (Does that handle class_init) ?
I don't understand the question. Do you want to instantiate an object?
If yes, just do the same as the re
The tcl parser (lib/parse.imc) has been removed and migrated to a method in a
PMC.
(Anyone looking for a C task could go through and cleanup the parse method in
tclparser.pmc - it's basically copied directly from the assembler style with
many gotos, no loops, etc. If you make changes, just make
Switching tclobject seems to work fine here. I suspect you might have something
else going on.
Committed the change to tclobject, removed my local hack to src/pmc.c, passes
100% now.
Regards.
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
Attached is a patch that allows "(cd langu
Jeff Horwitz wrote:
On Mon, 14 Mar 2005, William Coleda wrote:
How does one call a PIR-defined sub from C?
use the Parrot_call_sub_* API.
Ah, thank you, much better.
Now, given the perldoc for src/extend.c,
"void* Parrot_call_sub(Parrot_INTERP interpreter, Parrot_PMC sub,
How does one call a PIR-defined sub from C?
My current best guess is, to invoke the PIR sub "Tcl::Joe":
PMC *invokeme;
STRING *Tcl,*joe;
Tcl = string_from_const_cstring(INTERP, "Tcl", 3);
joe = string_from_const_cstring(INTERP, "joe", 3);
invokeme = Parrot_find_global(INTER
y cd'd...
it's actually in 'runtime/parrot/library/config.imc'
Is this what you're looking for?
William Coleda wrote:
Already exists.
perldoc parrot/library/config.imc
Regards.
Lambeck (via RT) wrote:
# New Ticket Created by Lambeck # Please include the string: [perl
Whoops, had already cd'd...
it's actually in 'runtime/parrot/library/config.imc'
Is this what you're looking for?
William Coleda wrote:
Already exists.
perldoc parrot/library/config.imc
Regards.
Lambeck (via RT) wrote:
# New Ticket Created by Lambeck # Please include t
Already exists.
perldoc parrot/library/config.imc
Regards.
Lambeck (via RT) wrote:
# New Ticket Created by Lambeck
# Please include the string: [perl #34356]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34356 >
It would b
So Dan's string stuff has been rolled into cvs main (along with a huge # of leo
addon patches...)
What's the current status of the new GC system? Still need testing?
I'd recommend postponing any of the architectural/design items that were slated
for 0.1.12 to 0.2.0 at the latest, perhaps anot
To avoid a warnocking,
Yup. Stopped in briefly on #parrot about 2 weeks ago, but basically MIA.
Leo is currently working on release 0.1.12.
Jesse is working on getting the TPF milestones more documented.
Regards.
Edward Peschko wrote:
hey,
just thought I'd take parrot's pulse really quick.. las
in src/library.c (main branch), I find:
const char*
Parrot_get_runtime_prefix(Interp *interpreter, STRING **prefix_str)
{
static STRING *s;
static int init_done;
static const char *prefix;
int free_env;
char *env;
if (!*runtime_prefix)
return NULL;
if (!init_done) {
After some distractions I got back to this today.
After doing the merge and resolving all the conflicts (of which there really
weren't that many), I get it to build, and then get a:
0x0002c3b0 in string_index (interpreter=0xd001a0, s=0x3002fd8, idx=0) at
src/string.c:747
747 return (INTVA
Just did a fresh checkout and now I no longer get test failures on OS X. (not
specifying a -prefix)
Leopold Toetsch wrote:
Will Coleda wrote:
I don't know if this is related to my build problems on OS X which
have gone warnocked. Trying to build without specifying a --prefix to
Configure causes
Thanks to Matt Diephouse, about 30+ tickets have just been properly marked as
resolved. (Though I physically closed them, he did all the legwork. Someone
make him a bugadmin, please.)
This leaves 268 documented issues in RT, plus whatever is lurking in CVS. >50% of
these are -new-, despite the f
did a fresh checkout and build... large number of dynclasses tests failed.
I then made clean, configured with prefix=`pwd`... now the build itself fails:
oolong:~/research/parrot_strings coke$ make
Compiling with:
xx.c
cc -g -pipe -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe
-fno-c
ickets are closed and the release is cut, we can close the release
ticket.
Please let me know if you would like me to make the use.perl.org announcement
again for this incremental release.
Regards.
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
What needs to be comple
This is now moved and updated.
No cvs magic was used in the relocation of this file.
William Coleda wrote:
If it's an example, let's move it to "example/c/test_main.c", then, and
update the comment in the beginning of the file that says:
=head1 DESCRIPTION
THIS FILE IS NO LO
What needs to be completed to cut 0.1.2 ? (0.1.1 was cut > 100 days ago)
Leo, Dan, if you can provide a list of tasks, I can work on the administrivia.
Thanks!
If it's an example, let's move it to "example/c/test_main.c", then, and update
the comment in the beginning of the file that says:
=head1 DESCRIPTION
THIS FILE IS NO LONGER USED.
with your note.
Brent 'Dax' Royal-Gordon wrote:
William Coleda <[EMAIL PROTECTED]>
Then lets remove the file to avoid further confusion.
Leopold Toetsch wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I don't find define of "Parrot_setflag()" in test_main.c.
src/test_main.c is unused. Why do you want to compile it?
leo
Consolidated DESIGN_TODO, KNOWN_ISSUES into the "ROADMAP".
If you have more details about any of these issues (Many of them were one
liners), please either:
o add the detail to this file, or
o open a ticket for the item with with detail.
Also, if you know that an item is obsolete, feel free to d
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
I had great plans to flesh it out more than I have, but work has
intruded. I've checked in what I have so far in docs/ROADMAP.
I really appreciate the effort putting all that together. But it's not
that simple. E
This week's Hall of Shame ticket is [perl #15308]
http://rt.perl.org/rt3/Ticket/Display.html?id=15308
Originally submitted in July of 2002 by Scott Walters, the only activity on the
warnocked ticket was a ping to the list in April of 2004 asking if someone
could rule on the patch. No followups we
Now that Dan's back, I'd like to make sure we have a roadmap in place for
moving forward.
I had great plans to flesh it out more than I have, but work has intruded. I've
checked in what I have so far in docs/ROADMAP.
I would like to eventually have every single outstanding task documented in RT,
This is a deployment of RT for issuings regarding http://www.parrotcode.org,
not the ticketing system for RT itself.
I would suggest checking http://www.bestpractical.com/rt/.
Regards.
prashanth (via RT) wrote:
# New Ticket Created by prashanth
# Please include the string: [perl #33815]
# in th
, what do you recommend? Is this /just/ because I'm using pir_compiler?
could I expect the same thing to happen to subs that are defined in the "Tcl"
namespace at the time the interpreter is begun?
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
Running t
What's going to happen to the perl6 work in progress that's in the parrot repository now that there is a separate svn repository?
Is it possible to:
1) define methods for a PMC/Object in C that aren't vtable methods? How?
2) call subroutines defined in bytecode from C? How?
Running the tcl "examples/bench.tcl" script, I get the following backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0021cb38 in Parrot_Sub_invoke (interpreter=0xd001a0, pmc=0xed2b60,
next=0xf20284) at classes/sub.c:239
239 if (interpreter->code->cur_cs != sub->se
Yes, I was using a regular expression, not a rules. =-)
Patrick R. Michaud wrote:
On Wed, Dec 29, 2004 at 08:09:10PM -0500, William Coleda wrote:
I'd like to get Tcl's [namespace] implemented, but this will be very
difficult until I can do:
$P0 = split "::+", $S0
or something
I'd like to get Tcl's [namespace] implemented, but this will be very difficult
until I can do:
$P0 = split "::+", $S0
or something equivalent with PGE.
Looks good, thanks.
Sam Ruby wrote:
William Coleda wrote:
(Resend from the right account so it'll make it to the list.)
This is on OSX. Looks very similar to an issue that I think Sam has
already fixed once. I have some tcl stuff pending that I can't verify
works in a clean build un
Not quite:
ld: multiple definitions of symbol _PROXY_STRING
pyproxytype.o definition of _PROXY_STRING in section (__DATA,__common)
pyproxyclass.o definition of _PROXY_STRING in section (__DATA,__common)
Sam Ruby wrote:
cvsuser 04/12/13 19:12:07
Modified:dynclasses pyproxyclass.pmc pyproxy
Can you give us a copy of the generated "myconfig" file in the top level parrot
directory?
Klaas-Jan Stol wrote:
Hello,
I just got a fresh cvs checkout, compiled it, compiled pge and tried to
make tcl.
This is what I get:
(cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc
languages/tc
Thanks, applied!
James deBoer wrote:
Attached is a patch that changes the split opcode to use an Array
instead of a PerlArray.
It also updates the documentation to note this.
All the tests still pass, and a grep in the languages/ directory shows
that no language implementations are effected.
-
Is there a plan at any point to move to an svn repository from cvs?
I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother.
You mean, someone actually tried to use Tcl? *Rub eyes*
Whoops. File got added to the tcl makefile based on a local copy of the command.
Committed update to MANIFEST and the join file (which isn't complete or tested,
btw.)
Try again?
Matthew Zimmerman (via RT) wrote:
# New Ticket Created by Matth
Thanks, applied.
Bernhard Schmalhofer (via RT) wrote:
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32868]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 >
Hi,
this patch adds a ta
Added some more list-based commands.
Added upvar (alias to caller's variables), uplevel (execute code in caller's
scope). (or your caller's caller, or...)
Also added a non-standard "inline" command so you can do:
oolong:~/research/parrot/languages/tcl/examples coke$ cat inline.tcl
inline PIR {
.s
A few issues with the recent CVS doings...
1) runtime/parrot/library/runtime/PGE.pir doesn't compile by default. Which it
can't, because:
2) PGE doesn't build by default. Should it? If so, then...
3) cd compilers/pge && make fails:
c++ -dynamiclib -L/usr/local/lib -flat_namespace -o pge.dylib pg
Should be working again, thanks to Josh Wilmes.
As a bonus, I found that one of my Tcl tests was unexpectedly succeeding.
A bit of a nit, but should the implementation & docs for the "does" opcode be moved to the
"pmc" file rather than the "object" file, since this is something available to every PMC? If
so, I can move it over.
I've also submitted a patch to the parrotcode site that adds the documentation for
"clas
Whoops. Perhaps Dan was merely stringing me along. =-)
Closing call.
Leopold Toetsch via RT wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
Based on a conversation with Dan in IRC, it should be possible to
interrogate PMCs about their generic type.
For example, tcl's [array exists varName] returns
Huh. That's annoying. attached trace for readability.
William Coleda wrote:
0 set P16, PMC_C[2]- P16=PMCNULL,
3 set I0, 1- I0=0,
6 set I1, 0- I1=0,
9 set I2, 0- I2=0,
12 set I3, 0- I3=1,
15 set I4, 0- I4=0,
Given IMC like:
.sub main @MAIN
$P1 = whee()
print $P1
.end
.sub whee
$P2 = new PerlString
$P2 = "leo\n"
.return ($P2)
.end
We get a trace like:
0 set P16, PMC_C[2]- P16=PMCNULL,
3 set I0, 1- I0=0,
6 set I1, 0- I1=0,
9 set I2, 0- I2=0,
1
Given IMC like:
.sub main @MAIN
$P1 = whee()
print $P1
.end
.sub whee
$P2 = new PerlString
$P2 = "leo\n"
.return ($P2)
.end
We get a trace like:
0 set P16, PMC_C[2]- P16=PMCNULL,
3 set I0, 1- I0=0,
6 set I1, 0- I1=0,
9 set I2, 0- I2=0,
1
Should the compilation sub for p6g3 be in the root namespace as it is currently, or moved to, say, a "p6ge" namespace?
Was an RT ticket ever created for the underlying parrot issue here?
Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #32547]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=
Finally added in rudimentary list support in tcl (using dynclasses/tcllist.pmc)
So the following tcl:
set a [list a b c]
lappend a d e f
puts [llength $a]
will now print 6. More list stuff to come soon, shortly after the exception-related test failures go away. =-)
uot;
And, again, exit value of 0.
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
I just noticed some test failures in the tcl suite.
exception syntax will change slightly.
set P4, P5["_invoke_cc"]
especially these constructs (resumable handling).
Please use curren
Data::Escape is probably your best bet.
.sub _main
load_bytecode "runtime/parrot/library/Data/Escape.pbc"
.local pmc escaper
escaper = find_global "Data::Escape";, "String"
$S0 = "\n"
$S1 = escaper($S0, "\"")
print $S1
print $S0
end
.end
Patrick R. Michaud wrote:
Is there some opcode or function b
I just noticed some test failures in the tcl suite.
Looks like the following code:
print "HERE?\n"
set_eh ignore
find_lex lexical, -1, var
clear_eh
Does the following at runtime:
3713 print "HERE?\n"
HERE?
3715 set_eh P20 - P20=Exception_Handler=PMC(0xf8eb30)
3717 find_lex P18, -1,
Is there a reason why we have "find_type", but "loadlib"; "eq_str" but "isnull" ?
Here's a simple report of new/open tickets from RT.
It's generated using the RT command line tool Robert just pointed me at (plus
some perl scripts)
Feedback about what's useful, not, and missing is appreciated.
Once we have a decent idea of what sort of report will be useful, Robert can
generate
Whoops, thanks applied.
Bernhard Schmalhofer via RT wrote:
It looks like the the 'all' target wasn't properly changed, when
applying the patch.
Applying the updated patch from ticket 31643 should fix this.
CU, Bernhard
Is it sufficient to provide a mechanism for the compiler writers to indicate
that tail call should be used? For example, I have a few cases in tcl where I
have something like:
($I0,$P0) = interpret($P1)
.return($I0,$P0)
Where I'd be happy to have to write:
.return_tailcall(interpret($P1))
or s
"Thanks, Applied"
Dan Sugalski wrote:
At 3:51 PM +0100 11/4/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Are we comfortable adding the dynclasses to the default build target?
I think it can go in.
Done.
That is to say, the file and line number appear to be off.
Will Coleda via RT wrote:
Also, the errors message isn't reporting properly.
Help?
oolong:~/research/parrot/include/parrot coke$ uname -a
Darwin oolong 7.5.0 Darwin Kernel Version 7.5.0: Thu Aug 5 19:26:16 PDT 2004;
root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC Power Macintosh powerpc
perl is "v5.8.1-RC3"
All tests successful, 4 tests and 52 subtests skipped.
Files=122, Tests=1943,
Leopold Toetsch via RT wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
I noticed after a recent update that parts of the tcl test suite
started failing. I finally tracked it down to the fact that I was NOT
running with '-G'.
tcl.pl dies at 19, removing "or die" fixes that.
In my rush to get check
Danke. Making this a macro was, at least, a step up from the function call I had.
I haven't done anything real with the PMCs yet (just cargo-culted them mostly from
their Perl* counterparts)
Though I have to wonder how this will work with inter-language-operability.
Thanks, Leo.
Leopold Toetsch wr
1 - 100 of 144 matches
Mail list logo
