paths:
M S02-bits.pod
Log Message:
---
[S02] use a better example for process globals
%*PID is not mentioned or explained anywhere else
On Fri Feb 13 20:46:31 2009, ch...@chrisdolan.net wrote:
If you include statements in the body of a package, class, etc.
declaration, those are executed at :load time which happens
before :main. So, globals like @*ARGS which are set up in !
UNIT_START from :main are not yet established
On Tue Jul 27 18:07:28 2010, coke wrote:
On Fri Feb 13 20:46:31 2009, ch...@chrisdolan.net wrote:
If you include statements in the body of a package, class, etc.
declaration, those are executed at :load time which happens
before :main. So, globals like @*ARGS which are set up
are executed at :load time which happens
before :main. So, globals like @*ARGS which are set up in !
UNIT_START from :main are not yet established. All three of the
following examples should have the same results, but the middle one
is wrong. Either setup of globals needs to happen before
...@parrotcode.org wrote:
On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote:
IMCC currently relies on a lot of static globals to carry state, and
cannot reliably restore them when an error occurs. (grep for
static and FIXME global in the IMCC tree.)
Allison had ruled that reentrancy should
On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT
parrotbug-follo...@parrotcode.org wrote:
On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote:
IMCC currently relies on a lot of static globals to carry state, and
cannot reliably restore them when an error occurs. (grep for
static
On Thu, Feb 12, 2009 at 6:09 PM, kjstol parrotc...@gmail.com wrote:
On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT
parrotbug-follo...@parrotcode.org wrote:
On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote:
IMCC currently relies on a lot of static globals to carry state
currently relies on a lot of static globals to carry state, and
cannot reliably restore them when an error occurs. (grep for
static and FIXME global in the IMCC tree.)
Allison had ruled that reentrancy should be possible for IMCC, and
this would be a good refactoring project.
We've rejected
# New Ticket Created by Ahmad Zawawi
# Please include the string: [perl #59570]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59570
Hi,
With this patch, $*OS and $*EXECUTABLE_NAME are now working.
However, $?...
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #57578]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57578
r29919:
../../parrot perl6.pbc -e '$*STUFF'
# no output
I don't think that's in
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46683]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46683
In src/pmc/eval.pmc:destroy() there is the todo item:
* These globals
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40743]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40743
Implement the stub routine 'globals' in languages/tcl/runtime/builtin/info.pir
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think of, and given the existing .HLL directive, its meaning
is immediately
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think
On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but we have a three-way
logic here, so
Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but
Chip Salzenberg wrote:
Hrm. Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think of, and given the existing .HLL directive, its meaning
is immediately clear:
I like that.
Seems to me
On Mon, Jul 10, 2006 at 06:57:06PM -0700, Matt Diephouse wrote:
Patrick R. Michaud [EMAIL PROTECTED] wrote:
I really like both of these suggestions. We also noted on #parrot that
get_hll_global would really simplify things for the Tcl folks, which
currently go through a macro to achieve the
On Mon, Jul 10, 2006 at 07:22:21PM -0700, Allison Randal wrote:
Chip Salzenberg wrote:
I think that hll is the best I can think of, and given the existing
.HLL directive, its meaning is immediately clear:
I like that.
Great!
Seems to me that we should have get_namespace patterned just
On Thu, Jul 06, 2006 at 05:39:45PM -0700, jerry gay wrote:
am i silly to think that if i'm looking for globals from the current
namespace, they're just as likely to be found closer to the namespace
root, than further away? perhaps something like
.namespace [ 'Foo'; 'Bar' ]
$P0
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
Chip Salzenberg [EMAIL PROTECTED] wrote:
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation
namespace) with no clear home.
Agreed.
* All the things being accessed are globals. Seems like the word global
should be used consistently, and symbol has many meanings in Parrot
that only partly overlap the specific meaning of global.
Agreed.
* We still don't have way to ask for my
Matt Diephouse wrote:
So for the runtime (this is the HLL runtime, not the PIR runtime, btw)
we're all set. Arrays fill the need perfectly and let us access the
root HLL namespace. That makes me think that we don't need any new
opcodes.
Chip's latest simplification eliminates the need for
Chip Salzenberg wrote:
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys. And this makes keys even more compatible
On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote:
The problem is really that we're trying to simultaneously a) refer to
the root HLL namespace directly, and b) pretend that it doesn't exist.
I don't think (b) is quite true. It's more that we're avoiding explicit
re-coding of a
Allison Randal wrote:
I had a much longer reply, but I'm going to let it steep overnight and
see what percolates.
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully specified namespace,
Chip Salzenberg wrote:
On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote:
The problem is really that we're trying to simultaneously a) refer to
the root HLL namespace directly, and b) pretend that it doesn't exist.
I don't think (b) is quite true. It's more that we're avoiding
On Thu, Jul 06, 2006 at 12:11:47PM -0700, Allison Randal wrote:
It's essentially the linguistic problem of being able to refer to
something both by its full name and by the pronoun it. (Otherwise known
as topic.) Only, currently it isn't represented by a word.
Well, we have three distinct
categories (global and symbol) leaves the third
category (current namespace) with no clear home.
* All the things being accessed are globals. Seems like the word global
should be used consistently, and symbol has many meanings in Parrot
that only partly overlap the specific meaning of global
' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
am i silly to think that if i'm looking for globals from the current
namespace, they're just as likely to be found closer to the namespace
root, than further away? perhaps something like
.namespace
Allison Randal [EMAIL PROTECTED] wrote:
Chip Salzenberg wrote:
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys.
# New Ticket Created by Audrey Tang
# Please include the string: [perl #39714]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39714
IMCC currently relies on a lot of static globals to carry state, and
cannot reliably
find_global [], 'foo' . Otherwise find_global becomes a
two step operation for finding globals in the root HLL namespace.
Well, that's a bit problematic. The [] syntax is inherited from the key
syntax, and keys currently can't be empty. The use of keys is a hack, but
it's a very convenient hack
# New Ticket Created by Will Coleda
# Please include the string: [perl #38119]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38119
All globals mentioned in http://www.tcl.tk/man/tcl8.5/TclCmd/
tclvars.htm must
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37247]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37247
* get rid of the still existing globals, move all into appropriate
structures
or a lexical.
Globals:
.local pmc ns
.include interpinfo.pasm
ns = interpinfo .INTERPINFO_NAMESPACE_ROOT
delete ns[foo]
(untested - see also t/pmc/namespace.t)
Lexcials:
.local pmc pad
pad = peek_pad
delete pad[foo]
(see also t/pmc/scratchpad.t)
leo
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #36623]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36623
There's currently no way to delete a global or a lexical.
chip mdiep: you
Hi,
I've not been keeping very up to date in recent times of how this stuff
is working. I've been noticing the use of these variables within pugs
and have a slight suggestion.
Currently there is rather limited abstraction with these items (as far
as I am aware) and while they are usable and
On Wed, Apr 20, 2005 at 08:45:02PM +0100, Scott McWhirter wrote:
: Hi,
:
: I've not been keeping very up to date in recent times of how this stuff
: is working. I've been noticing the use of these variables within pugs
: and have a slight suggestion.
:
: Currently there is rather limited
On Wed, Apr 20, 2005 at 08:45:02PM +0100, Scott McWhirter wrote:
: Why would this be useful? Why should anyone care? Well, a real world
: example would be if I wished to find out through a large codebase to
: locate all the areas within the codebase that are calling $?OS. To do
: this, I would
I've moved a lot of the globals into the imc_info structure. The PASM
and PIR compilers are basically re-entrant now (there are likely some
issues with line numbers in error reports).
To achieve this a lot of functions got an interpreter argument, which
unfortunately makes the patch rather big
Currently, Parrot_find_global throws and internal_exception, which is IMO not
good.
I have a patch ready that adds a void *next parameter to
- Parrot_find_global
- Parrot_store_global
and adds
- Parrot_find_global_nspmc (PMC *namespace instead of STRING *namespace)
- Parrot_store_global_nspmc
Jens Rieks [EMAIL PROTECTED] wrote:
Currently, Parrot_find_global throws and internal_exception, which is IMO not
good.
Where? The Parrot_find_global() function returns NULL in failure case.
Parrot_get_global() throws a real execption.
I have a patch ready that adds a void *next parameter to
1) and 2) are:
1) needs more knowledge about thawed PMCs (put Subs into the globals...)
2) needs a thaw option to extend the given (hash) PMC, but is much simpler
Thougts?
leo
Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:06 AM +0200 8/8/03, Leopold Toetsch wrote:
This is an unordered list of issues - mainly design questions - about
the specific implementation of some parts.
Interpreter globals
---
We have real globals (e.g. Parrot_base_vtables, Env
work well with AUTOLOAD, so they probably don't require
Cuse statements. Anyways, I'd rather have Cuse statements than
globals. I know others disagree -- I even disagree when I'm
trying to write a one-liner on the command line.
Perl 6 is the community rewrite. One of the pillars of the
community
Folks,
We have global variables. (And have for some time, according to the
commit logs)
I've tweaked core.ops a little, made sure the global symbol table is
part of the root set for the GC, and added in a test for it.
Anyone got anything else on the todo list that's actually done? :)
--
Dan wrote:
Yep, I've seen their plans. It's less an issue for us, at least as
far as globals are concerned, since we'll be doing that with
lexicals. (Python not having lexicals, after all) Globals are a bit
more interesting, since bytecode-loaded modules can't guarantee
global positions, since
At 3:05 PM +0100 2/13/02, Angel Faus wrote:
Dan wrote:
Yep, I've seen their plans. It's less an issue for us, at least as
far as globals are concerned, since we'll be doing that with
lexicals. (Python not having lexicals, after all) Globals are a bit
more interesting, since bytecode-loaded
At 12:54 AM -0500 2/10/02, Melvin Smith wrote:
I know globals are still on the todo, but what is the plan for the
operands of these opcodes? I see PMC examples, but will
we also have versions of these for the native int, string and number
Parrot types?
Nope, I'm not planning on that. We can add
I know globals are still on the todo, but what is the plan for the
operands of these opcodes? I see PMC examples, but will
we also have versions of these for the native int, string and number
Parrot types?
-Melvin
52 matches
Mail list logo
