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,
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
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
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 "
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
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
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
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
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/
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
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
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
Is it possible to do substitutions with PGE yet? If so, how?
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
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
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
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
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
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
"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.
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
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
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
Patrick R. Michaud wrote:
P6GE assumes that it is part of the parrot distribution in the
F directory. Simply type C in this directory
to build the F shared library it needs.
oolong:~/research/parrot/compilers/p6ge coke$ make
cc -I ../../include -c -o p6ge_parse.o p6ge_parse.c
p6ge_parse.c:2
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,
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
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. =-)
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=
Should the compilation sub for p6g3 be in the root namespace as it is currently, or moved to, say, a "p6ge" namespace?
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
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
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
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
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.
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.
-
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
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
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
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.
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
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
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?
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?
, 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
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
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 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
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
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
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
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]>
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!
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
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
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
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
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
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
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) {
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
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
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
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
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
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
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,
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
ghc of 6.2 on OS X 10.3 with pugs svn-latest.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/builtins/goto.t1 256?? ?? % ??
t/builtins/grep.t
Here's another round with version 1192, OS X; more tests, but more failures,
too:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/builtins/goto.t1 256?? ??
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
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
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:
(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
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?
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
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
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
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
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
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
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
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).
'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
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
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
-
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
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.
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
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
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
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
Leopold Toetsch wrote:
I think, we have to split the main MANIFEST a bit into:
- core
- ICU
- languages
Why?
- cvs updates that hit MANIFEST take really long and are likely to collide
- language maintainers, who only have privs for their language
directory, should be able to do *all* needed chang
Update to the Tcl Interpreter - primary update is better separation between the
parser/interpreter (in preparation for replacing the interpreter with a compiler)
Minor updates neeed outside languages/tcl attached.
Tested against cvs latest, everything I expected to pass passes.
Index: MANIFEST
==
Leopold Toetsch wrote:
- TclInt
- TclFloat
- TclObject
- TclString
This is a small subset of PMCs enumerating *current* scalars. I can't
imagine that e.g. tcl is happy, when a tcl scalar falls back to a morphing
variant of a Perl scalar. OTOH just doing the math operations would be
fine. So what'
I currently have some special handling for when a user defines a proc in Tcl.
Right now, when someone defines a proc, I parse out the body of the proc immediately, and save
it and some metadata in a global hash. Then, at interpreter time, I have special logic that (a)
checks to see if it the proc
my freeze/thaw is basically going to amount to freezing my
single attribute (another PerlArray of PerlArrays of...). Will it be kosher to have my
__freeze method simply call freeze on the attribute and return the result?
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
I
28915 was resolved by the time I got to it, I closed 29653 as "notabug".
Regards.
Jerome Quelin wrote:
On Monday 17 May 2004 18:50, you wrote:
Ticket 28915 is resolved, but I don't have rt rights to change its
status: can somebody close it please?
Oh, and ticket 29653 (fake one) too.
Jerome
I've been trying to wrap my head around freezing and objects. My current
understanding is that:
o parrotclass extends delegate
o delegate's freeze vtable entry is Parrot_delegate_freeze
o Parrot_delegate_freeze should delegate the freeze vtable method to PASM.
However, when parrotclass.pmc is comp
I was going to submit this as a patch, but I ended up with a conflict, and Dan
threatened he wouldn't apply it anyway, so I'll just post it here for comment. Feel
free to apply any or all of it. I would be very happy to hear of a better way to
answer the first question. =-)
---
=head2 How do I
Recent changes to tcl:
2004-05-28
* put all user-visible procs into "Tcl" namespace, especially
user-defined procedures.
* put all interpreter-only procs into "_Tcl" namespace
* factor out non-tclsh-specific setup into lib/tcllib.imc
* first cut at: $P1 = compre
1 - 100 of 139 matches
Mail list logo
