On 2/10/22 02:25, Elizabeth Mattijsen wrote:
Have you considered giving back to the community by putting this into a module
(as well as the WinMessageBox and WinMount modules that it refers to, which I
assume to be your private modules) and uploading it to the ecosystem?
I have considered. O
> On 10 Feb 2022, at 11:10, ToddAndMargo via perl6-users
> wrote:
> That is an interesting module. I am not sure what
> I would use it for though. Maybe in the future.
> It is a method of find out what a drive is.
>
> What I was after was finding the drive letter that
> corresponded to a logic
On 2/10/22 01:26, Elizabeth Mattijsen wrote:
So I was really hoping for a built in system32 call.
I really, really don't care for the the trouble
associated with using the "C" interface to call
system 32 dll's, but I may have to.
One of the things that Raku tries to do, is to be ignorant about
> So I was really hoping for a built in system32 call.
> I really, really don't care for the the trouble
> associated with using the "C" interface to call
> system 32 dll's, but I may have to.
One of the things that Raku tries to do, is to be ignorant about the underlying
OS.
Having a system32 D
On 2/9/22 12:18, ToddAndMargo via perl6-users wrote:
On 9 Feb 2022, at 12:37, ToddAndMargo via perl6-users
wrote:
Hi All,
Windows 7,10,11
Do we have a command/function that will show all drive
letter and their labels?
Many thanks,
-T
On 2/9/22 04:05, Elizabeth Mattijsen wrote:
> W
On 9 Feb 2022, at 12:37, ToddAndMargo via perl6-users
wrote:
Hi All,
Windows 7,10,11
Do we have a command/function that will show all drive
letter and their labels?
Many thanks,
-T
On 2/9/22 04:05, Elizabeth Mattijsen wrote:
> What would you use on a command-line to get t
drive
> letter and their labels?
>
> Many thanks,
> -T
>
>
> --
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~
Hi All,
Windows 7,10,11
Do we have a command/function that will show all drive
letter and their labels?
Many thanks,
-T
--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~
# New Ticket Created by Alex Jakimenko
# Please include the string: [perl #126200]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126200 >
Code:
outer: loop { loop { last owter; } };
Result:
===SORRY!=== Error while compiling
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #120632]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=120632 >
perl6: label1: say "OH HAI"; label1: say "OH NOES"
rakudo-parrot 60c8c1, rakudo-jvm 60c
# New Ticket Created by Minimiscience
# Please include the string: [perl #67660]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=67660 >
Rakudo is unable to parse the following program. It runs correctly if
the "loopBlock
#x27;s implicit like for "continue").
>
> You're correct that PCT doesn't have support for 'goto' yet, and
> yes, it will. However, the typical model for this is likely to
> be based on control exceptions instead of using branches and labels.
> To borr
From: Larry Wall <[EMAIL PROTECTED]>
Date: Thu, 24 Jan 2008 09:52:16 -0800
In addition to what Patrick said, which is all right on the mark,
I'd like to point out a few additional subtleties.
Perl borrows an important idea from Lisp and separates the notion
of stack unwinding fr
o wrinkles for implementing goto the
way Perl wants it. First, you have to collect the labels in each
lexical scope and store them somewhere (along with their addresses)
in case someone wants to goto them from some inner dynamic scope.
(You can't just assume goto will come from an inner lexica
On Jan 24, 2008 9:02 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 11:58:02AM -0500, Mark J. Reed wrote:
> > Sorry if I'm missing something here, since I haven't dived into the
> > innards of Parrot, but I thought control flow in Parrot was based on
> > continuations?
On Thu, Jan 24, 2008 at 11:58:02AM -0500, Mark J. Reed wrote:
> Sorry if I'm missing something here, since I haven't dived into the
> innards of Parrot, but I thought control flow in Parrot was based on
> continuations? Presumably 'control exceptions' are really just
> lexicaly-scoped exceptions,
Sorry if I'm missing something here, since I haven't dived into the
innards of Parrot, but I thought control flow in Parrot was based on
continuations? Presumably 'control exceptions' are really just
lexicaly-scoped exceptions, and exceptions are in turn just
outgoing-only continuations. If you h
Statements like "break", "next", "last", "continue" typically take a label
> as an argument (or it's implicit like for "continue").
You're correct that PCT doesn't have support for 'goto' yet, and
yes, it will.
ly take a label
as an argument (or it's implicit like for "continue").
For a HLL, these "labels" are typically not visible for the programmer
(although I think Perl does support this, with nested loops and labels).
My idea is this: what if there's a :pasttype('got
Klaas-Jan Stol wrote:
PDD19 states that labels are not allowed for directives, which in
practice means, that the following is not allowed:
foo: .local int i
It would be useful to add some rationale about this in the PDD, if it
is really necessary; why is this limitation?
Labels are
PDD19 states that labels are not allowed for directives, which in
practice means, that the following is not allowed:
foo: .local int i
It would be useful to add some rationale about this in the PDD, if it
is really necessary; why is this limitation?
I assume this limitation would then also go
hi,
attached a patch indicating that labels may only be written within a
compilation unit, which is more or less implied in the current description.
it could be rephrased for style.
kjs
Index: docs/pdds/draft/pdd19_pir.pod
Klaas-Jan Stol schrieb:
I wonder in what case it's useful to have a "normal" .local directive in a
macro (with its normal semantics).
Every time the macro is expanded, the same local var. would be declared,
which can't be good.
As far as I understand it, PIR macros a simple text replacements w
On 10/2/07, Allison Randal <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> >>> The big overall cunning plan is to remove ".local" for this purpose
> >>> (defining labels), and to use ".local" ONLY for declaring variab
[EMAIL PROTECTED] wrote:
The big overall cunning plan is to remove ".local" for this purpose
(defining labels), and to use ".local" ONLY for declaring variables.
Then, once all ".local" (in macros) are replaced by ".label", we can
start replacing &q
On Sep 28, 12:45 am, [EMAIL PROTECTED] (Bernhard
Schmalhofer) wrote:
> Klaas-Jan Stol schrieb:> hi,
>
> > attached a patch that adds ".label" as a directive to declare labels
> > in a macro.
> Applied in r21624.
thanks!
>
> > The big overall cunning
Klaas-Jan Stol schrieb:
hi,
attached a patch that adds ".label" as a directive to declare labels
in a macro.
Applied in r21624.
The big overall cunning plan is to remove ".local" for this purpose
(defining labels), and to use ".local" ONLY for declaring varia
hi,
attached a patch that adds ".label" as a directive to declare labels in a
macro.
The big overall cunning plan is to remove ".local" for this purpose
(defining labels), and to use ".local" ONLY for declaring variables.
Then, once all ".local" (in
I'm currently fixing #37590 and removed tons of code from imcc/pbc.c.
The changes are causing a more strict error checking WRT label usage
and a slight restriction WRT labels in PASM code:
.pcc_sub foo:
...
branch foo
is now illegal. In practice there is probably always a get_params
Jonathan Worthington (via RT) wrote:
Don't have time to track this down myself right now, but if you do
parrot -o it.pbc it.pir
With the attached, it segfaults.
Thanks, fixed - r10089
leo
f you do
parrot -o it.pbc it.pir
With the attached, it segfaults. Yes, I *know* the code won't run 'cus it's
missing labels. I discovered this bug by accident - the PIR is actually
being generated from a work-in-progress tool that didn't generate the
destinations of the jumps at
>> 1989 /*
>>(dbx)
>>
>>The line->label is an impossible pointer, so deferencing causes promptly
>>a bus error.
>>
>>
>>
>
>
> Jarkko,
>
> Can you restest and confirm that this is still an issue with pdb?
These seems to have been fixed.
> Thanks,
>
> -J
>
>
...
(I'd still like the bareword-ish labels to go away)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
On Tue, Apr 26, 2005 at 11:24:34AM -0600, Luke Palmer wrote:
: That's true, but the former hasn't been accepted. That's not something
: I considered when I was thinking about that proposal, but I think it's
: a fairly minor issue. We'll ignore labels as we continue to w
diom (syntactic
complexity for semantic simplicity should indicate deprecated
constructs, and as far as I know, no one is deprecating labels).
* Tagging might be useful in other situations where a keyword
would be useful for visually marking the construct. I have no
meter to the looping statement function
for :label 1... { next "foo" };
This makes labels somewhat less general, but maybe C should be
handled separately, anyway. For example, maybe you can only use C
if you've asked to "use continuations;".
Aaron Sherman skribis 2005-04-26 16:40 (-0400):
> Is there ever a reason for a leading adverb in a statement or control
> structure?
List of pairs and left-to-right writing:
:foo, :quux ==> map { ... } ==> my @baz;
> or you could have a keyword that introduces the label:
> rx/label +
On Tue, 2005-04-26 at 13:24, Luke Palmer wrote:
> [we'll] redo label syntax later if we must.
Well, of course you run the danger of making it hard for people to
recognize labels which are otherwise common across many languages, but
here's a few ways you could do labels if you need
Juerd writes:
> Luke Palmer skribis 2005-04-26 9:28 (-0600):
> > Labels are pretty easy to pick out. I don't believe there is any other
> > thing in the language that, at the beginning of a statement, matches
> > /\w+\:/ . They are certainly available in Perl 6 (as are
Luke Palmer skribis 2005-04-26 9:28 (-0600):
> Labels are pretty easy to pick out. I don't believe there is any other
> thing in the language that, at the beginning of a statement, matches
> /\w+\:/ . They are certainly available in Perl 6 (as are plain old line
> labels; we&#
Stevan Little writes:
> Hello all,
>
> I have been going over the Synopsis, and I cannot find block labels
> mentioned anywhere. I was under the impression that if it is not
> mentioned, then it can be assumed to be the same as perl5. However, I
> wonder if this is the case
Hello all,
I have been going over the Synopsis, and I cannot find block labels
mentioned anywhere. I was under the impression that if it is not
mentioned, then it can be assumed to be the same as perl5. However, I
wonder if this is the case with labels given that "everybody wants the
> On Mon, Dec 06, 2004 at 10:28:45PM -0600, Andy Lester wrote:
> I think even better than
>
> ok( $expr, "name" );
>
> or
>
> ok( $expr, "comment" );
>
> is
>
> ok( $expr, "label" );
>
> RJBS points out that "comment" implies "not really worth doing", and I
> still don't like "name" be
I don't really agree that "comment" implies "not really worth doing". I
think
those inclined to not put a name/comment/label on their test will not
do it
whatever we end up calling it. IMO the only way to get people to do it
would
be to make it required, and I don't think that is a good idea.
I
On Mon, Dec 06, 2004 at 10:28:45PM -0600, Andy Lester wrote:
> I think even better than
>
> ok( $expr, "name" );
>
> or
>
> ok( $expr, "comment" );
>
> is
>
> ok( $expr, "label" );
>
> RJBS points out that "comment" implies "not really worth doing", and I
> still don't like "name" beca
On Tue 07 Dec 2004 05:28, Andy Lester <[EMAIL PROTECTED]> wrote:
> I think even better than
>
> ok( $expr, "name" );
>
> or
>
> ok( $expr, "comment" );
>
> is
>
> ok( $expr, "label" );
or ok ($expr, "indicator");
or ok ($expr, "tag");
for me the name/comment/label/tag/indicator/... is
I think even better than
ok( $expr, "name" );
or
ok( $expr, "comment" );
is
ok( $expr, "label" );
RJBS points out that "comment" implies "not really worth doing", and I
still don't like "name" because it implies (to me) a unique identifier.
We also talked about "description", but "desc
ith duplicate local labels.
Also label fixup handling is different so just don't compile
PIR files to PASM except for debugging.
from imcc/BUGS
# New Ticket Created by Will Coleda
# Please include the string: [perl #31160]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31160 >
Make breakpoints at labels
(From the TODO file)
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #30997]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=30997 >
The PDB labels are somehow b0rked in tru64/alpha:
(make pdb)
kosh:/tmp/
At 12:16 PM -0800 1/19/04, TOGoS wrote:
Hi.
In IMCC, how can I get the address of a label in a
different compilation unit?
Don't. The only way to transfer control to code in a different
compilation unit (arguably in a different sub in the same compilation
unit) is via invoke or one of its relati
Hi.
In IMCC, how can I get the address of a label in a
different compilation unit? Is there a way to do this
at compile time? I've looked through the latest docs
but according to imcc/docs/parsing.pod, global labels
get stored in global variables that you must look up
at run time (yuck)
Luke Palmer <[EMAIL PROTECTED]> wrote:
[ bug ]
I've fixed it somehow - still calling conventions stuff is missing.
(the register allocator will happily globber the return continuation in
the sub if not written explictely as P1).
This works now:
.sub _main
newsub P0, .Sub, _foo # n
Luke Palmer <[EMAIL PROTECTED]> wrote:
> The following doesn't work:
[ snip ]
> Indeed, it can be done by using C and C, but shouldn't sub
> names be considered global labels, too?
Of course. But newsub and the whole calling convention stuff isn't
finished yet. Mea
The following doesn't work:
.sub _main
newsub $P0, Sub, _foo
invokecc $P0
end
.end
.sub _foo
# ...
.end
Indeed, it can be done by using C and C, but shouldn't sub
names be considered global labels, too?
Luke
Clinton A. Pierce <[EMAIL PROTECTED]> wrote:
> Causes "In main's FOO" to be printed twice. While an understandable
> behavior, probably not the correct one.
... and not the documented one.
I did not strictly implement the documented behavior of global/local
labels un
or, probably not the correct one. Language in parsing.pod indicates
that perhaps the labels should be munged by IMCC. If this *is* the
correct behavior, then a "duplicate label" error of some kind should be
emitted by IMCC.
The next upcoming change in imcc will fix the until yet not "carved in
stone" rules:
global labels MUST start with an underscore
local labels SHOULD NOT start with an underscore
global labels are subject to address fixup, which is done for subroutine
calls (bsr) and for the "se
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16960]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16960 >
imcc and assembler did allow duplicate labels.
Fix for imcc is ready and foll
In message <[EMAIL PROTECTED]>
"David M. Lloyd" <[EMAIL PROTECTED]> wrote:
> On Sat, 13 Jul 2002, Tom Hughes wrote:
>
> > Of course... The attached patch should handle that I think...
>
> This patch is breaking several Solaris 32-bit tests. The following
> assembly (from t/pmc/perlar
On Sat, 13 Jul 2002, Tom Hughes wrote:
> Of course... The attached patch should handle that I think...
This patch is breaking several Solaris 32-bit tests. The following
assembly (from t/pmc/perlarray1.pbc):
new P0,.PerlArray
set P0,0
set I0,P0
print I0
Applied, thanks..
\']*(?:\\.[^\\\']*)*)\'
+ )x;
$self->{pc}++;
return if $line=~/^\s*$/ or $line=~/^\s*#/; # Filter out the comments and blank
lines
- $line=~s/#[^'"]+$//; # Remove trailing comments
+ $line=~s/^((?:[^'"]+|$str_re)*)#.*$/$1/; # Remove trailing comments
$line=~s/(^\s+|\s+$)//g; # Remove leading and trailing whitespace
#
# Accumulate lines that only have labels until an instruction is found..
vision 1.77
> diff -u -r1.77 assemble.pl
> --- assemble.pl 4 Jul 2002 18:36:17 - 1.77
> +++ assemble.pl 13 Jul 2002 17:30:48 -
> @@ -433,7 +433,7 @@
>
>$self->{pc}++;
>return if $line=~/^\s*$/ or $line=~/^\s*#/; # Filter out the comments and blank
>lines
> - $line=~s/#[^'"]+$//; # Remove trailing comments
> + $line=~s/#.*$//; # Remove trailing comments
>$line=~s/(^\s+|\s+$)//g; # Remove leading and trailing whitespace
>#
># Accumulate lines that only have labels until an instruction is found..
# Remove trailing comments
+ $line=~s/#.*$//; # Remove trailing comments
$line=~s/(^\s+|\s+$)//g; # Remove leading and trailing whitespace
#
# Accumulate lines that only have labels until an instruction is found..
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #757]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=757 >
This code:
A:# prints "a"
print "a"
end
doesn't assem
The following items are now patched and tested:
Multiple labels converging on a single instruction. (Tested in
t/op/basic.t)
Labels and constants now match the format [a-zA-Z_][a-zA-Z0-9_]* (Tested
in t/op/macros.t)
P3[7], P3[0x1a], P3[-0b10101], P4[S1], P5["Hello World"] all work.
Tes
ike this:
LBL1:
LBL2:
print "hello\n"
this patch tweaks the part of the assembler which joins empty labels
with the following lines so that the assembler now sees.
LBL1: noop
LBL2: print "hello\n"
instead of LBL1:LBL2: print "hello\n" which was confusing the heck
9_]*);
+ my $label_re = qr([a-zA-Z_][a-zA-Z0-9_]*);
my $pc = 0;
$self->_collect_labels(); # Collect labels in a separate pass
--
"TIMTOWTDI, but did you have to pick the ugliest way you could find?"
-- Michael Carman in comp.lang.perl.misc
At the moment, the assembler doesn't seem to like single character
labels. For instance, this code:
bsr aa
print "Didn't branch \n"
end
aa: print "Branched \n"
end
prints "Branched", as one would expect, but this co
I've commited a change which allows local labels to be used in parrot.
The labels are local relative to the last non-local label defined (i.e.
local labels are forgotten when a non-local is defined).
Here's my test program:
main: print "test 1\n"
bra
All --
The labels autogenerated by the Jako compiler use uppercase characters
and underscores. This patch makes the opcode inference logic in the
assembler happy with that situation. It also prints out the qualified
opcode it inferred when it fails to find a matching opcode.
Regards
On Wed, Sep 05, 2001 at 09:02:00PM -0400, Bryan C. Warnock wrote:
> Hmm is this such a good thing?
Using goto LABEL? No. ;)
Would be nice if Perl warned one about multiple labels of the same
name in the same call stack, though.
> my $a = 0;
> GORK: while( 1 ) {
>
Hmm is this such a good thing?
my $a = 0;
GORK: while( 1 ) {
print "Rin ";
GORK: if ( 1 ) {
print "Tin ";
goto GORK if $b ^= 1;
print "\n";
next GORK;
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
nce per iteration,
> implicitly; so using C explicitly to mean "no further iterations"
> is highly counterintuitive, or at least inconsistent.
What if we could use C to exit valued iterators? Currently we cannot
because labels can not appear within statements, only on their own.
75 matches
Mail list logo
