> >>
> >>> 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
> >>> > "s
te:
>>> > 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.)
>>> >
>>> &g
On Thu, Feb 12, 2009 at 6:09 PM, kjstol 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 t
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 er
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46683]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46683 >
In src/pmc/eval.pmc:destroy() there is the todo item:
* These globals st
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40743]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40743 >
Implement the stub routine 'globals' in languages/tcl/runtime/builtin/in
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 pat
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 achie
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
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 absolut
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
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
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 immediat
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
{ 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
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
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 crea
ot;symbol") leaves the third
category (current 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 spe
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 rea
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
am i silly to think that if i'm looking for global
at's my job now :-))), in descending order of difficulty:
* The division into two 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"
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 disti
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 ex
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, in
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
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 wi
ce [] > so that we could also have the
> matching C< 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 c
# New Ticket Created by Audrey Tang
# Please include the string: [perl #39714]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39714 >
IMCC currently relies on a lot of static globals to carry state, and
cannot relia
# New Ticket Created by Will Coleda
# Please include the string: [perl #38119]
# in the subject line of all future correspondence about this issue.
# 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.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37247 >
* get rid of the still existing globals, move all into appropriate
structu
bal 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.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36623 >
There's currently no way to delete a global or a lexical.
mdiep: you should be
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 rathe
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" paramet
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 (
es between 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
>>---
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? :)
--
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 bi
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&#x
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 plannin
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
42 matches
Mail list logo
