On 2019-12-05 23:39, ToddAndMargo via perl6-users wrote:
Hi All,
Its there a way, if you import a module that is also
imports a bunch of constants into your main program
to be used globally?
If so, what is the syntax in the module and in the main program?
And what happends if there is a name
On Fri, 6 Dec 2019 at 09:05, ToddAndMargo via perl6-users
mailto:perl6-us...@perl.org>> wrote:
On 2019-12-06 00:01, Tom Blackwood wrote:
> Todd,
>
> AFAIK Perl’s culture is not to use so many constants in actual
> programming. :)
>
> To
,
> >
> > AFAIK Perl’s culture is not to use so many constants in actual
> > programming. :)
> >
> > Tom
> >
>
> Is there a way to make constants universal inside a module, or
> do I have to declare them inside every sub?
>
--
Simon Proctor
Cognoscite aliquid novum cotidie
http://www.khanate.co.uk/
On 2019-12-06 00:01, Tom Blackwood wrote:
Todd,
AFAIK Perl’s culture is not to use so many constants in actual
programming. :)
Tom
Is there a way to make constants universal inside a module, or
do I have to declare them inside every sub?
Todd,
AFAIK Perl’s culture is not to use so many constants in actual programming.
:)
Tom
On Fri, Dec 6, 2019 at 3:47 PM ToddAndMargo via perl6-users <
perl6-us...@perl.org> wrote:
> Hi All,
>
> Its there a way, if you import a module that is also
> imports a bunch of consta
Hi All,
Its there a way, if you import a module that is also
imports a bunch of constants into your main program
to be used globally?
If so, what is the syntax in the module and in the main program?
And what happends if there is a name conflict between
the module and main program?
Many thanks
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #129266]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129266 >
NOTE: This is fixed in HEAD, but is broken in 2016.08.1-143-gc9b18c6. I'm
opening the tic
# New Ticket Created by Steve Schulze
# Please include the string: [perl #126974]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126974 >
If I build constant arrays, use those arrays to built _other_ constant
arrays
with meta
Thanks Liz,
I will stick with the method aproach.
Regards,
Emiliano
> Subject: Re: Constants as members of a class
> From: l...@dijkmat.nl
> Date: Fri, 18 Dec 2015 23:49:53 +0100
> To: perl6-us...@perl.org
>
> > On 18 Dec 2015, at 23:37, TS xx wrote:
> >
> &
> On 18 Dec 2015, at 23:37, TS xx wrote:
>
> Hi Liz, thanks for your reply.
>
> Can I call the method from static context?
> I mean: MyClass.FOO
In general, yes:
class A {
method FOO { 42 } # note the method doesn’t reference any attributes
}
say A.FOO;
say A.new.FOO; # also works on in
Hi Moritz,
I need a constant static field in the class.
I think the method aproach will do it.
Thanks & Regards,
Emiliano
> Date: Fri, 18 Dec 2015 13:29:44 +0100
> From: mor...@faui2k3.org
> To: perl6-us...@perl.org
> Subject: Re: Constants as members of a class
>
> Hi,
Hi Liz, thanks for your reply.
Can I call the method from static context?
I mean: MyClass.FOO
> Subject: Re: Constants as members of a class
> From: l...@dijkmat.nl
> Date: Fri, 18 Dec 2015 10:23:11 +0100
> To: perl6-us...@perl.org
>
>
> > On 18 Dec 2015
Thanks anyway
The new method is there just to state the example.
Date: Thu, 17 Dec 2015 22:58:32 -0500
Subject: Re: Constants as members of a class
From: awwa...@thelackthereof.org
To: maringa...@hotmail.com
CC: perl6-us...@perl.org
Two things jump out at me. One is that I think you don't
Hi,
On 12/18/2015 03:46 AM, TS xx wrote:
> Hello dear perl6 users,
>
> I was in the need of declaring a member variable as a constant integer.
I don't understand this. If it's a constant, why does it need to be
member at all? A member is per-instance storage, which seems to be a
waste for a cons
() {
> return self.bless();
> }
>
> submethod BUILD () {
> constant $!myConst = 1;
> }
>
> method showMyConst () {
> print $!myConst;
> }
> }
>
> But I'm getting the followinf error message: "Twigil-Variab
owinf error message: "Twigil-Variable constants not yet
implemented. Sorry."
The only place in the docs where I have found any reference to constants is in
here: https://doc.perl6.org/language/variables#The_%3F_Twigil
But it's not what I am looking for :/
So my questions are:
Is the
; submethod BUILD () {
> constant $!myConst = 1;
> }
>
> method showMyConst () {
> print $!myConst;
> }
> }
>
> But I'm getting the followinf error message: "Twigil-Variable constants
> not yet implemented. Sorry."
>
> The only place in
;
}
method showMyConst () {
print $!myConst;
}
}
But I'm getting the followinf error message: "Twigil-Variable constants not yet
implemented. Sorry."
The only place in the docs where I have found any reference to constants is in
here: https://doc.perl6.org/lan
# New Ticket Created by dakkar
# Please include the string: [perl #125975]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=125975 >
Consider this snippet:
constant NOW = DateTime.now;
That is a BEGIN-time declaration + init
nbrown++ added a test to S02-literals/heredocs.t with commit
https://github.com/perl6/roast/commit/9b7d709fd7.
I'm closing this ticket as 'resolved'.
masak: I think https://rt.perl.org/Ticket/Display.html?id=117853 can
get a test (if there isnt' already one) and be closed now?
jnthn: yep. was gonna add that to the ticket.
* masak adds it now
On Sun, Dec 15, 2013 at 11:28:02AM -0500, Parrot Raiser wrote:
: It's not really a constant he wants, but a value that's read-only to
: everything but the setting routine. Some sort of object, perhaps?
Any parameter to sub MAIN is readonly by default, since parameters
in general are readonly by de
It's not really a constant he wants, but a value that's read-only to
everything but the setting routine. Some sort of object, perhaps?
Hi Richard,
On 12/12/2013 08:56 AM, Richard Hainsworth wrote:
I would like to set a series of magic numbers from the command line.
I have in a program
constant N-SCENARIOS = 10;
which works great. But I would like to set an option in the command
line, such as
perl6 program.p6 scenarios=15
.
I would like to set a series of magic numbers from the command line.
I have in a program
constant N-SCENARIOS = 10;
which works great. But I would like to set an option in the command
line, such as
perl6 program.p6 scenarios=15
and then within program have the option assigned to the constant
:
M S11-modules.pod
Log Message:
---
Constants, enums and (our) variables are also exportable (I hope)
rakudo b2072f: OUTPUT«===SORRY!===Premature heredoc consumption»
what in the world does "Premature heredoc consumption" mean? :(
is it unreasonable to want to put a heredoc string in a
constant? I don't think so.
masak: It means that constants are evaluated immediately
masak: It'
# New Ticket Created by grond...@yahoo.fr
# Please include the string: [perl #117853]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=117853 >
This is perl6 version 2013.04-32-gc66c428 built on parrot 5.2.0
revision REL
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #114246]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=114246 >
I dunno whether rakudo supports importing constants yet
y
Message:
---
generics can produce constants without declarator
For the purposes of determining whether a variable is declared
constant, it is not enough to consider whether the C
declarator has been used. Generic code that instantiates parameters
with constant arguments can also produce
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #72750]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=72750 >
rakudo: sub foo(5) { say "HAI 5!" }; foo(5)
rakudo 1d4928: OUTPUT«HAI 5!»
rakudo: su
# New Ticket Created by Lewis Wall
# Please include the string: [perl #70720]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=70720 >
[20:20] rakudo: say :(3).perl
[20:20] <+p6eval> rakudo 7347ec: :(Int ::TYPE_CAPTURE20 whe
9: OUTPUT«No applicable methods. [...]
[...]
ouch, that looks like a rakudobug
rakudo: constant $a = 3; say $a
rakudo d749d9: OUTPUT«3»
i was trying to define many constants in a compact way
masak: care to submit? :-)
* masak cares to submit
std: constant ($a, $b) = 1, 2; say "$a $b"
std 28773: OUTPUT«ok 00:02 115m»
# New Ticket Created by "Martin Berends"
# Please include the string: [perl #65548]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=65548 >
Declaring constants and using them in the same file works, but moving
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #64522]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=64522 >
rakudo: say ++e
rakudo 0310a3: OUTPUT«3.71828182845905»
* masak submits rakudobug
as
On Tuesday 01 July 2008 09:23:58 NotFound wrote:
> This patch solves the issue, the lexid string was stored before truncating
> it.
Thanks, applied (with Patrick's test case) as r28911.
-- c
=
--- compilers/imcc/pbc.c (revisión: 28897)
+++ compilers/imcc/pbc.c (copia de trabajo)
@@ -1161,8 +1161,8 @@
unit->lexid->name = str_dup(unit->lexid->name + 1);
/* Otherwise, create string constant for it. */
+ unit->lexid->nam
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56508]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56508 >
In r28897:
$ cat x.pir
.sub 'main'
'foo'()
'bar'()
.end
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf Of Mark J. Reed
>Sent: Monday, April 14, 2008 2:05 PM
>To: Jonathan Worthington
>Cc: David Green; Perl6
>Subject: Re: Idea: infer types of constants
>
>On Mon, Apr 14
TSa wrote:
Jonathan Worthington wrote:
Miller, Hugh wrote:
Was that private communication or on another mailing list?
It was also sent to perl6-language, through I was on the To or Cc line
too, so I guess that's how I got it but the list, somehow, didn't. Not
sure why the original message I r
HaloO,
Jonathan Worthington wrote:
Miller, Hugh wrote:
Was that private communication or on another mailing list?
What is the type of $b? Well, we can't actually infer that because foo
might be:
sub foo() {
$OUTER::a = "oh hi, i iz not int!"
}
That should be $CALLER::a because $OUTER
Miller, Hugh wrote:
What about the type support (system) one sees in ML ? (e.g., the way it
assigns automatically types can be assigned, does not require specific
types when they are not needed, flags incompatibilities, etc.) Do those
things not fit well with Perl's approaches and aims ?
They
HaloO,
John M. Dlugosz wrote:
Then the declaration
my ::T $x = whatever;
should use the exact same generic mechanism! At worst, it needs
I would expect that this works by binding ::T to the type of whatever.
my Any ::T $x = whatever;
Any here is optional.
and it will introduce th
Mark J. Reed markjreed-at-mail.com |Perl 6| wrote:
On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington
my Dog $fifi .= new(); # works in Rakudo too ;-)
And even in Pugs! :) Doesn't help with literals, though, e.g.
my Float $approx_pi = 3.14;
So the idea of marking the use of
To me the foo looks like a template sub and I wonder how it is
instanciated with different types. Since type parameters are
provided with [] it should be foo[Int], foo[Str] and the like.
I wonder further if that could also be written foo of Str like
with Array of Int etc.
my foo of Int &intfo
On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington
> my Dog $fifi .= new(); # works in Rakudo too ;-)
And even in Pugs! :) Doesn't help with literals, though, e.g.
my Float $approx_pi = 3.14;
--
Mark J. Reed <[EMAIL PROTECTED]>
Mark J. Reed wrote:
I don't care for the use of * there, but it would be nice to have some
way to declare the variable to have the type implied by its
initializer, where the complier can tell what that is, so you could
remove the redundancy in this:
my Dog $fido = new Dog();
while still allowin
strong typing and static types
> > should say that the compiler =will= implicitly get the type for $pi
> > rather than making it Any.
>
> Except if constants infer their type and other variables don't, that's
> one more special case to remember. What if there were a
ny.
Except if constants infer their type and other variables don't, that's
one more special case to remember. What if there were a quick and
unobtrusive way to get the type of the value instead of "Any"? Can we
use a "whatever" type?
my * $x =
HaloO,
Brandon S. Allbery KF8NH wrote:
our ::T sub foo (T $a, T $b)
without needing to introduce a new twigil syntax for type variables.
My reading as well. But I would write it sub foo (::T $a, T $b --> T)
for better indicating that ::T is taken from the parameters.
(Although I would won
On Apr 13, 2008, at 2:02 , John M. Dlugosz wrote:
In Perl 6, I think you would have to arrange to write the return
type later rather than sooner to do this:
sub foo (::T $a, T $b)
is of T
and writing it the other way around would violate the one-pass
parsing.
Just from looking at thi
I'm thinking that if strong typing is enabled, mixing untyped and typed
things will cause warnings or errors that need not be there.
I'm thinking that 'constant' is more special than other variables, and
that the formal description of strong typing and static types should say
that the compiler
John M. Dlugosz wrote:
> Just surfing, I noticed something about the "D" programming language:
>
> "
> The types of constants need not be specified explicitly as the compiler
> infers their types <http://en.wikipedia.org/wiki/Type_inference> from
&
Just surfing, I noticed something about the "D" programming language:
"
The types of constants need not be specified explicitly as the compiler
infers their types <http://en.wikipedia.org/wiki/Type_inference> from
the right-hand sides of assignments.
const fact_7 = Fac
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46123]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46123 >
In src/debug.c:PDB_cond() there is the todo item:
else if (condition->type & PDB_cond_
On Tue Apr 03 10:37:13 2007, particle wrote:
> lib/Parrot/Pmc2c/PCCMETHOD.pm contains a number of constants, defined
> for use in the package. these constants should be generated during the
> configure process and included, following the DRY principle (don't
> repeat yoursel
Leo,
In the discussion around RT #41291, I think I heard you say something about
the code:
CONTEXT(interp->ctx)->constants =
PMC_sub(sub)->seg->const_table->constants;
(seen for example in Parrot_call_sub() in src/extend.c). Do I remember
correctly that you
# New Ticket Created by Jerry Gay
# Please include the string: [perl #42286]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42286 >
lib/Parrot/Pmc2c/PCCMETHOD.pm contains a number of constants, defined
for use in
On Thu, Sep 28, 2006 at 09:36:13AM +0100, Nicholas Clark wrote:
>
> However, step 2 is easier for Perl because we're not trying to do portable
> bytecode. Some constants, (such as *most* of the socket constants, but I think
> not all) are defined in RFCs, so can be baked into by
On Fri, Sep 08, 2006 at 12:38:39PM +0200, Leopold Toetsch wrote:
> Hi,
>
> typical socket ocde currently looks a bit unfriendly due to magic constants,
> e.g.
>
> socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp
>
> I'd like to have symbolic
All sounds good up to:
Larry Wall wrote:
The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.
If you see a bare function name you should generally assume it
has arguments in Perl 6.
Well, in that case, s
Am Samstag, 9. September 2006 22:27 schrieb Kevin Tew:
> check out the newly added languages/c99
> Its a start at a PGE grammar for C99
Whut? Whut?
Whutzeesayin'?
just 3 lines of svn log messages - and I've missed these ;-)
++tewk
leo
chromatic wrote:
On Friday 08 September 2006 03:38, Leopold Toetsch wrote:
typical socket ocde currently looks a bit unfriendly due to magic
constants, e.g.
socket sock, 2, 1, 6# PF_INET, SOCK_STREAM, tcp
I'd like to have symbolic constants for all that stuff:
socket
On Friday 08 September 2006 03:38, Leopold Toetsch wrote:
> typical socket ocde currently looks a bit unfriendly due to magic
> constants, e.g.
>
> socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp
>
> I'd like to have symbolic constants for all that stuff:
>
Hi,
typical socket ocde currently looks a bit unfriendly due to magic constants,
e.g.
socket sock, 2, 1, 6# PF_INET, SOCK_STREAM, tcp
I'd like to have symbolic constants for all that stuff:
socket sock .PF_INET, .SOCK_STREAM, .PROTO_tcp
Appended is a C snippet, which pro
On Thursday 17 August 2006 21:27, David Green wrote:
> However, what I'm wondering is whether Order::Same is "but true" and
> the others "but false"? (Which makes cmp in boolean context the same
> as eqv, but it seems to make sense that way.)
OTOH, C programmers can as well assume 'cmp' being an
I don't know if I've made this clear, but over the last few years I've
been treating "but True" and "but False" as design smells. They're
fine as a workaround for dire circumstances and uncooperative types,
but you'll not find me designing very many of the core interfaces to
use them, or other run
On Thu, Aug 17, 2006 at 11:27:21AM -0600, David Green wrote:
: However, what I'm wondering is whether Order::Same is "but true" and
: the others "but false"? (Which makes cmp in boolean context the same
: as eqv, but it seems to make sense that way.)
We should not be encouraging people to use c
On 8/17/06, Reed, Mark (TBS) wrote:
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
Maybe you could view it e
-- Original message --
From: "Reed, Mark (TBS)" <[EMAIL PROTECTED]>
> S03, lines 418-420: "[cmp] always returns C,
> C, or C (which numerify to -1, 0, or +1)."
>
> Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
> which case it would be cl
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
"Matt Diephouse" <[EMAIL PROTECTED]> wrote:
The following code in lines 108-110 of languages/tcl/src/class/
tclcommand.pir are giving parrot some trouble:
inlined.emit(" if epoch != %0 goto dynamic_%1", epoch, label_num)
inlined .= retval
inlined.emit(" goto end_%0", label_num)
I
via RT Matt Diephouse <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39597]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39597 >
The following code in lines 108-110
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39597]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39597 >
The following code in lines 108-110 of languages/tcl/src/class/
tclcommand.pir are g
Adam Kennedy wrote:
Forgive my ignorance here, but for all of these different ways of doing
constants, will they all optimize (including partial
evaluation/currying) at compile/build/init/run-time?
my $gravity is constant = 10; # One significant figure
sub time_to_ground ($height, $accel
[EMAIL PROTECTED] (Adam Kennedy) writes:
> Forgive my ignorance here, but for all of these different ways of
> doing constants, will they all optimize (including partial
> evaluation/currying) at compile/build/init/run-time?
Gosh, I hope not.
> my $gravity is constant = 10; # One
Ingo Blechschmidt wrote:
Hi,
# Way 1
my $MEANING_OF_LIFE is constant = 42;
Forgive my ignorance here, but for all of these different ways of doing
constants, will they all optimize (including partial
evaluation/currying) at compile/build/init/run-time?
my $gravity is constant = 10
Hi,
"TSa (Thomas Sandlaß)" wrote:
> Ingo Blechschmidt wrote:
>> Or did you simply forget the braces around 42? :)
>
> No, it was intented for seeing what the reactions will be :)
:)
> Just using &foo as unsigiled variable. This might need
>
> my &foo is rw;
I don't think this will DWYW, as fi
Ingo Blechschmidt wrote:
is that allowed (as 42 is a Num (or an Int), not a Code)?
I don't know, but guess not.
Do (most of) the basic types morph themselves into Codes, when needed?
I don't consider it type morphing. If your examples parse
at all they will be dispatched as usual
say 4
Hi,
"TSa (Thomas Sandlaß)" wrote:
> my &MEANING_OF_LIVE = 42; # But might be considered evil sigilless
> mode
is that allowed (as 42 is a Num (or an Int), not a Code)?
Do (most of) the basic types morph themselves into Codes, when needed?
say 42();# 42?
say "Perl"();
Ingo Blechschmidt wrote:
# Please add more ways :)
enum ;
my &MEANING_OF_LIVE = 42; # But might be considered evil sigilless mode
--
TSa (Thomas Sandlaß)
Hi,
# Way 1
my $MEANING_OF_LIFE is constant = 42;
# Way 2
my &MEANING_OF_LIVE = -> () { 42 };
# or
sub MEANING_OF_LIVE () { 42 }
# Then one can use sigilless constants:
say MEANING_OF_LIVE;
# Way 3 (still possible?)
use constant MEANING_OF_LIVE => 42;
# W
1) the PASM and PIR assemblers are now extended to understand arbitrary
PMC constants:
.const .Integer P0 = "42" # PASM
.const .Integer i = "42"# PIR
.const Integer i = "42"# PIR
Caveat: don't use this yet, the PMC constants vanish a
On Fri, Mar 18, 2005 at 03:38:38PM +0800, song10 wrote:
: hi, all
:
: is there any way to import constants from other modules without
: specifying scope everytime?
: such like this:
:
: module A;
: use constant { PI => 3.14, VER => 1.1 }
: ...
:
:
:
: module B;
: my $var = A::PI;
hi, all
is there any way to import constants from other modules without
specifying scope everytime?
such like this:
module A;
use constant { PI => 3.14, VER => 1.1 }
...
module B;
my $var = A::PI; # this way is fine when A is 'short' or rare
imagination
module C;
Ok, next is committed. The existing constant syntax is extended:
.const var_or_ident = "initstring"
Currently only subroutine constants are supported, e.g.
.const .Sub $P0 = "foo"
.const .Sub func = "foo"
The actual opcode emitted is "sub_p_pc" wi
A first patch is in CVS. Imcc now understands the syntax:
set_p_pc P0, 0 # load PMC constant no. 0
The explicit arguments are necessary to disambiguate
set P0, 0 # assign integer 0 to P0
This isn't much useful per se, as a compiler/you doesn't know the
constant index of a PMC co
# New Ticket Created by Will Coleda
# Please include the string: [perl #31154]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31154 >
Dumping constants shouldn't unpack the constants, but
just print
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> $ cat big.pasm
>new P0, .BigInt
>set P0, 18446744073709551615
>print P0
>print "\n"
>end
> $ ./parrot ~/big.pasm
> 9223372036854775807
> $
> This on a 64-bit system (tru64 alpha), substitute 4294967295 for the
> 184467440737095516
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #30896]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=30896 >
$ cat big.pasm
new P0, .BigInt
set P0, 18446744073709551615
print P0
separate the
> float, pmc, and string constants into separate tables for
> locality-of-reference reasons and ease of doing reflective access.
The constants are currrently a typed union, so there is some wasted
space. OTOH constants compiled at the same time tend to stick together
(modulo constan
At 8:30 AM +0200 4/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The interpreter stuff's simple enough--we teach the ops preprocessor
to handle them the same way that it does string constants, and index
into the PMC constant table. We'll want to put th
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The interpreter stuff's simple enough--we teach the ops preprocessor
> to handle them the same way that it does string constants, and index
> into the PMC constant table. We'll want to put them in a separate
> part of the
At 4:39 PM +0200 4/16/04, Leopold Toetsch wrote:
While trying to speed up hash lookups [1] I came (again) to the
problem that we are missing true PMC constants. We just have a
special Sub PMC for storing subroutine entries but no general way to
represent a constant PMC item. E.g.:
.const
While trying to speed up hash lookups [1] I came (again) to the problem
that we are missing true PMC constants. We just have a special Sub PMC
for storing subroutine entries but no general way to represent a
constant PMC item. E.g.:
.const pmc s = "value"
.const pmc i = 1
Explicit constants to opcodes like warnings{on,off} and errors{on,off}
are likely to change in the future. Please use the constants from
warnings.pasm or errors.pasm.
so don't do:
errorsoff 1
but
.include "errors.pasm"
errorsoff .PARROT_ERRORS_GLOBALS_FLAG
leo
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> On Saturday 06 March 2004 13:55, Bernhard Schmalhofer wrote:
>>
>> this patch is just a little documentation update in 'docs/iterator.pod'.
> This file is automatically generated from classes/iterator.pmc
Actually the patch is against docs/pmc/iterat
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> this patch is just a little documentation update in 'docs/iterator.pod'.
> Now named constants are used for setting up the iterator in the examples.
Thanks, applied.
leo
tml?id=27469 >
>
>
> Hi,
>
> this patch is just a little documentation update in 'docs/iterator.pod'.
> Now named constants are used for setting up the iterator in the examples.
This file is automatically generated from classes/iterator.pmc
> There was even a littl
ator.pod'.
Now named constants are used for setting up the iterator in the examples.
There was even a little bug, .ITERATE_FROM_END is no longer 3, but 4.
There is now also a PIR test in 't/pmc/iter.t'.
CU, Bernhard
--
/* [EMAIL PROTECTED] */
+++ NEU bei GMX und erstmalig in Deu
1 - 100 of 177 matches
Mail list logo
