Just to add my 2 cents here, I've always felt that there should be basic
primitives provided, and the HLL can take care of the rest. Technically the
low-level IO routines don't have to know about encoding or compression
schemes at all. A VM provides the building blocks, and you can add whatever
Also, unless things have changed, multiple op dispatch cores are
built in standard Parrot. I'm behind on my reading the list, so
someone will correct me if I missed it, but last time I worked with
the code there were 5 cores, just for experimental reasons.
Ideally, for production the config will
I originally wrote IMCC was a separate module, and I even released it on CPAN.
For a long time it lived in languages/imcc but Leo rolled it in at some point.
Copyrighting my code does not limit my ability to contribute it to a project
under a dual copyright. I have never heard what the final
At 07:15 AM 6/12/2005, Chip Salzenberg wrote:
Therefore, register allocation must allow for implicit flow of control
from *every* function call to *every* function return ... or, more
precisely, to where *every* continuation is taken, including function
return continuations.
Yes.
But for
At 01:16 PM 6/12/2005, MrJoltCola wrote:
At 07:15 AM 6/12/2005, Chip Salzenberg wrote:
1) As far as variable lifetime, the brute-force method would assume
lifetime windows (du-chains) from the first definition of each variable
to the last function call in a basic block. Horrible for optimization
At 01:40 PM 6/3/2005, Matt Fowles wrote:
I have been working and thinking about improvements to the Parrot/IMCC
optimizer for a while now. Implementing SSA is definitely at the top
of my list, because it simplifies a lot of optimizations and makes
some others possible. The biggest
Actually no, from the PIO routines you should return a PMC
that has a null handle, or that was my original intent. I think
I was considering changing new_io_pmc() to return something
like ParrotUndef in that case but never did. The very first
version of the IO routines actually did return NULL for
At 01:10 PM 4/28/2005, Dan Sugalski wrote:
At 5:57 PM +0200 4/28/05, Robin Redeker wrote:
On Wed, Apr 27, 2005 at 03:43:32PM -0400, Dan Sugalski wrote:
At 5:40 PM +0200 4/27/05, Robin Redeker wrote:
The expense is non-trivial as well. Yeah, it's all little tiny bits
of time, but that adds up.
At 04:52 PM 4/18/2005, chromatic wrote:
On Mon, 2005-04-18 at 14:44 +0200, Leopold Toetsch wrote:
Yep. As a first step, I'd redefine this to be C.label:
.macro SpinForever (Count)
.label $LOOP: dec .COUNT# .label $LOOP defines a local label.
branch .$LOOP # Jump
At 02:33 PM 4/13/2005, Dan Sugalski wrote:
At 8:25 PM +0200 4/13/05, BÁRTHÁZI András wrote:
An other question is, that how can you tell to the platform, to limit
these features, maybe non-modifiable environment variables and command
line parameters can be the ways of it.
For that you need a
At 03:49 PM 4/13/2005, BÁRTHÁZI András wrote:
I'm not a UNIX guru, but I don't know an easily installable solution for
the problem. I would like to run just one Apache, and would like to run
Perl as an Apache module. Chroot I think is not a solution for it. Running
the script as CGI or running
At 06:57 PM 4/11/2005, Matt Diephouse wrote:
Now that IMCC is a core part of Parrot, I'd like to see the imcc/
directory go away. I'd be willing to spend some time trying to prepare
some patches (it'd be a good way to become more familiar with the
source), but I have a few questions first:
(1) Is
At 10:03 AM 4/8/2005, wolverian wrote:
To get to the real topic:
In Perl 6, the generic solution to fix this (if one wants to fix it)
seems, to me, to be to add a .eval method to objects that represent
scopes. I'm not sure if scopes are first class values in Perl 6. Are
they? How do you get the
At 03:21 AM 4/7/2005, Leopold Toetsch wrote:
MrJoltCola [EMAIL PROTECTED] wrote:
At 06:24 PM 4/6/2005, Chip Salzenberg wrote:
* What platforms are required for release? I'd guess that we'd get
almost of all of our developers (and users, for that matter) with:
darwin
linux
At 12:32 PM 4/7/2005, Chip Salzenberg wrote:
According to Peter Sinnott:
I set up a tinder server a couple of weeks ago.
Not sure if anyone else looks at it.
http://unlinked.vm.bytemark.co.uk/tinder//parrot/status.html
I understand that tinderbox is an automated system for test builds
with
At 06:24 PM 4/6/2005, Chip Salzenberg wrote:
* What platforms are required for release? I'd guess that we'd get
almost of all of our developers (and users, for that matter) with:
darwin
linux-x86-gcc3.*
win32-ms-cl
You should round that out with 64-bit Sparc.
-Melvin
At 10:28 PM 4/6/2005, Chip Salzenberg wrote:
According to MrJoltCola:
At 06:24 PM 4/6/2005, Chip Salzenberg wrote:
* What platforms are required for release? I'd guess that we'd get
almost of all of our developers (and users, for that matter) with:
darwin
linux-x86-gcc3
At 04:00 PM 4/4/2005, via RT wrote:
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #34669]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34669
The creators of flex were rather mean to go and
At 06:33 AM 4/1/2005, Nick Glencross wrote:
Having never had access to a Tru64 system, does that mean that parrot is
compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platform. It was hoped that it
At 05:57 PM 3/31/2005, Nigel Sandever wrote:
Is Parrot bytecode reentrant?
Yes.
That is, if I want to have two instances of a class in each of two
threads, will
the bytecode for the class need to be loaded twice?
No, just once.
Also, will it be possible to pass objects (handles/references)
At 04:08 PM 3/28/2005, Ron Blaschke wrote:
On the one hand, IMCC doesn't really help you _run_ code, so I'm not
inclined to see it part of libparrot. On the other hand, I haven't
grokked the entire code base organization, so I could be Greatly
Missing The Point.
On the gripping hand, if
At 04:44 PM 3/28/2005, Ron Blaschke wrote:
MrJoltCola wrote:
At 04:08 PM 3/28/2005, Ron Blaschke wrote:
On the one hand, IMCC doesn't really help you _run_ code, so I'm not
inclined to see it part of libparrot. On the other hand, I haven't
grokked the entire code base organization, so I
At 06:55 PM 3/21/2005, Chip Salzenberg wrote:
According to Dan Sugalski:
As such, I'd like to say a big thanks to Chip Salzenburg who's agreed
to take the hat.
I thank you for your kind words, and for giving me the opportunity
again to work long hours and explain difficult and arbitrary design
At 09:47 AM 3/11/2005, theUser BL wrote:
(with the languages Nice and Groovy) and .net, but written esecialy for
scripting-languages.
True, Parrot is slanted toward dynamic scripting languages that recompile
and eval themselves
on the fly, but it does provide low-level registers and features
At 07:50 AM 3/7/2005, Leopold Toetsch wrote:
Roger Browne [EMAIL PROTECTED] wrote:
On Mon, 2005-03-07 at 11:01 +0100, Leopold Toetsch wrote:
4.1.1) implement a language pragma in assembler, e.g.:
.HL_language Python
Sounds good to me except that I would prefer you remove the HL_
and just
At 03:21 AM 2/25/2005, Leopold Toetsch wrote:
MrJoltCola [EMAIL PROTECTED] wrote:
I feel that this feature is for higher level languages.
[ snip ]
... PIR is for compilers, not people,
PIR is foremost Parrot's primary assembly language. If it were for
compiles only, it wouldn't have needed a = b
At 11:48 AM 2/25/2005, Bernhard Schmalhofer wrote:
MrJoltCola wrote:
At 03:21 AM 2/25/2005, Leopold Toetsch wrote:
MrJoltCola [EMAIL PROTECTED] wrote:
I feel that this feature is for higher level languages.
[ snip ]
... PIR is for compilers, not people,
My impression was that the target
At 12:57 PM 2/25/2005, Steve Coleman wrote:
constructs that could not be logically mapped from other CPU's into
Parrot? Does Parrot assume/use many high level constructs not found in
real processors? Some CPU translations, like from CISC to RISC, are
clearly easier than the reverse, but other
At 01:27 PM 2/25/2005, vlad florentino wrote:
Is there now, or will there be in the future, any way to call C/C++
library routines from within Parrot? For example, a mysql, pcre or
libcurl library. Either static or dynamic.
C yes. C shares objects are dynamically loadable by Parrot.
C++? Not
This should actually be titled Where are all the compilers?
-
I haven't ranted in a couple of years, so I'm due. Ranting is
nothing more than broadcasting my emotions from a soapbox
but it is so fun, I love to do it.
Let me respectfully give my opinion. In no way am I criticizing your
At 01:40 PM 2/9/2005, Aaron Sherman wrote:
On Wed, 2005-02-09 at 12:08, [EMAIL PROTECTED] wrote:
I read that you can provide support (in Perl 6) for most languages that
parsers have been written for. As it appears to me, however, the
languages
that you are mainly interested in are substitutes
They are well defined at the moment, but the author's intent of the API was
to have them
mutable.
-Melvin
At 01:18 PM 2/1/2005, Leopold Toetsch wrote:
MrJoltCola [EMAIL PROTECTED] wrote:
Layer and layer API members may be changed at runtime. Yes, the current
structure
members are all static
Layer and layer API members may be changed at runtime. Yes, the current
structure
members are all static, but they don't have to be.
I would reverse this patch.
-Melvin
At 06:26 AM 1/31/2005, via RT wrote:
# New Ticket Created by François PERRAD
# Please include the string: [perl #34002]
# in
Thanks Robert for the fixup.
Nothing like throwing a grenade to get people scrambling.
-Melvin
-Original Message-
From: Robert Spier [EMAIL PROTECTED]
Sent: Oct 23, 2003 1:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [COMMIT] imcc moves out of languages
So much for preserving repository
On Wed, 21 Aug 2002 18:02:51 +0200 Angel Faus [EMAIL PROTECTED] wrote:
I think we all agree that since parrot can have dynamic oplibs (and core
parrot has hundreds of ops), imcc needs some way to directly express them.
The idea of having parrot ops be included as such, and imcc directives be
Can I respectfully request that you guys make a lot more of your
discussions public? languages/imcc and languages/perl6 are very major
components, and they have been very little discussed on-list. imcc
Sure, I have no problem with it. At one
time someone suggested making a separate
list for
On 02 Jul 2002 16:35:02 +0100 Tom Hughes [EMAIL PROTECTED] wrote:
I've done that for the register stacks, and I'll do the same for the
other stacks unless somebody spots a flaw in my logic and points out
that the GC will catch it...
No, your logic is correct, stacks are still
outside of
On Tue, 4 Jun 2002 10:06:44 -0700 (PDT) Larry Wall [EMAIL PROTECTED] wrote:
It's really not that difficult to run two interpreters in the
same process. I already made Perl and Java run together nicely.
Agree.
Scaffolding is supposed to be ugly. You wouldn't believe how ugly
the transitional
On Tue, 28 May 2002 12:50:06 +0200 Jerome Vouillon [EMAIL PROTECTED] wrote:
I propose the following alternate guidelines.
STRING * concat (STRING* a, STRING* b, STRING* c) {
PARROT_start();
PARROT_str_params_3(a, b, c);
PARROT_str_local_2(d, e);
d = string_concat(a, b);
Changes:
-Minor layer cleanups
-Win32 layer added (mostly stubs for now) but will be using the
Win32 API and company rather than the unix-ish fake ones.
-stdin/stdout/stderr Win32 specific code added. Rather than use
0,1,2, Microsoft says use GetStdHandle(), etc. so that stuff is
All who have time, specifically Win32, please test this
patch for compilation. I currently don't have a Win32
environment to test with. Anyone with non-Linux please test.
What this patch does:
-Implements initial IO stack framework (pushing/popping layers)
-Implements an initial layer for the
Oops. The patch helps.
-Melvin
diff -urN tmp/parrot/MANIFEST parrot/MANIFEST
--- tmp/parrot/MANIFEST Tue Jan 1 11:58:13 2002
+++ parrot/MANIFEST Tue Jan 1 16:40:01 2002
@@ -79,6 +79,8 @@
include/parrot/trace.h
include/parrot/unicode.h
interpreter.c
+io/io.c
+io/io_os.c
Can we start some dialogue about stream filters?
What form they take, are we talking regular expressions, etc.
-Melvin
Here is a start for the IO skeleton. I implemented
open, close, read, write, setbuf and some constants in io.h
-Implements a simple ParrotIO PMC with null vtable
-open() takes a string for mode which is Perl-ish (, , , |, +, +)
Comments? Would the group prefer numeric constants here?
In lieu of a de-allocator for mem_allocate_aligned I vote
we at least do something in the interim and I volunteer to
help as soon as someone decides what it is!
I know GC is on the way but...
At minimum we should be using plain malloc() until a
better solution or the current one is finished,
The only thing that needs the allocated alignment is some of the internal
pieces--the stack chunks and register frames, really. Everything else can
use a plain malloc. Well, mem_allocate, rather, which can be a wrapper
around malloc for now.
Dan
Maybe we can do this for now?
-Melvin
---
Dan wrote:
# In lieu of a de-allocator for mem_allocate_aligned I vote
# we at least do something in the interim and I volunteer to
# help as soon as someone decides what it is!
Maybe we can have a mem_free_aligned that somehow figures out what the
starting address is. If we do that and document
On Monday, December 10, 2001 10:44:09 AM Dan Sugalski wrote:
At 02:57 PM 12/10/2001 +, Simon Cozens wrote:
On Sun, Dec 09, 2001 at 11:26:44PM -0500, [EMAIL PROTECTED] wrote:
it has to do with the fact that the memory allocator
adjusts the address before returning the chunk and free()
While implementing one of my IO routines in core.ops I
used free_string() on a string that was created ultimately
with mem_allocate_aligned() and I get core dumps. I assume
it has to do with the fact that the memory allocator
adjusts the address before returning the chunk and free()
then gets
So for example, open in an int context does a raw open,
open in a scalar or PMC context does a fancy open (buffered
or whatever) and returns a IO object?
Also, if you want the interface to be the same for all
these ops, how do you want callbacks implemented?
1) Are we doing callbacks?
2) If so,
Here we go... Just adds the debug flag for test_prog.
-Melvin
--- orig/parrot/test_main.c Mon Oct 22 21:00:01 2001
+++ parrot/test_main.c Wed Dec 5 18:13:03 2001
@@ -20,6 +20,7 @@
int bounds_checking;
int profiling;
int tracing;
+int debugging;
struct
51 matches
Mail list logo
