Re: How to read a particular environmental variable?
It’s still a hash — the * twigil tweaks it’s scope, but it is still a % — so %*ENV works (windows) On Tue, Apr 7, 2020 at 6:48 PM ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: > Hi All, > > $ raku -e 'say %*ENV;' > > Gives me ALL of them. Is there a way to just ask for > a particular one, such as %appdata%, or %userprofile% > in Windows or $HOME is Linux? > > Many thanks, > -T >
Re: OAuth2?
Just looked at the stackoverflow post — there are 3 updates with respect to needing to reauthenticate. Basically, you use the ‘AUTH XOATH base64 oathtoken’ command, after the EHLO command. the weird part seems to be the ehlo command is repeated twice — before STARTTLS, and after. g On Sun, Mar 22, 2020 at 8:18 AM ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: > On 2020-03-21 22:56, Peter Scott wrote: > > On 3/21/20 2:20 PM, ToddAndMargo via perl6-users wrote: > >> On 2020-03-18 18:42, ToddAndMargo via perl6-users wrote: > >>> This is a long shot, but have any of you figured out > >>> how to send eMail through G-Mail with OAuth2? > >>> > >>> I have a module that uses cURL, but I can't figure > >>> out how to get it to work with OAuth2. > >>> > >>> RFE: please support OAuth2 > >>> https://github.com/retupmoca/P6-Net-SMTP/issues/24 > >>> > >>> Is in the works, but I need to get something going > >>> by June 2020 as s-suite will stop supporting > >>> Less Secure Apps at that time. > >> > >> Found this: > >> > >> python & smtplib: Is sending mail via gmail using oauth2 possible? > >> > >> > https://stackoverflow.com/questions/11445523/python-smtplib-is-sending-mail-via-gmail-using-oauth2-possible > >> > >> > >> But it is python we doh't have anything equivalent to > >> import oauth2 as oauth > >> import oauth2.clients.imap as imaplib > > > > I am in almost exactly the same situation. I don't need to send mail, > > but I do need to read Gmail through IMAP and rename folders and move > > messages. I am under the same deadline and have done extensive research > > without getting anywhere. The documentation and online Q do not get > > me very far. > > You may wish to sign up for this RFE/Bug I posted: > > RFE: please support OAuth > https://github.com/retupmoca/P6-Net-SMTP/issues/24 >
Re: bitwise NOT
A negative number (-A5) is the twos compliment of the positive number. A
ones compliment is all the bits flipped. A twos compliment is a ones
compliment plus one. So a ones compliment of (A5) is (-A5 - 1), which is
-A6.
So presumably, the twos compliment operator is (-). And I suppose for
consistency, +-A5 gives you -A5, which makes +- the twos compliment bitwise
operator..
On Tue, Jan 14, 2020 at 7:45 AM Paul Procacci wrote:
> >> What is the syntax for a twos complement anyway?
>
> I'm not sure I understand the question.
> Two's compliment is +^ ... the routine you've been using.
>
> On Tue, Jan 14, 2020 at 12:33 AM ToddAndMargo via perl6-users <
> perl6-users@perl.org> wrote:
>
>> >> On Mon, Jan 13, 2020 at 11:30 PM ToddAndMargo via perl6-users
>> >> mailto:perl6-users@perl.org>> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> This works,
>> >>
>> >> $ p6 'my uint8 $c = 0xA5; my uint8 $d = +^$c; say
>> $d.base(16);'
>> >> 5A
>> >>
>> >> But this does not:
>> >>
>> >> $ p6 'my uint8 $c = 0xA5; say (+^$c).base(16);'
>> >> -A6
>> >>
>> >> 1) who turned it into an negative integer?
>> >>
>> >> 2) how do I turn it back?
>> >>
>> >> Many thanks,
>> >> -T
>>
>> On 2020-01-13 21:18, Paul Procacci wrote:
>> > If you read the signature for +^, you'll notice it returns an Int.
>> >
>> > In your first working example, you're taking a uint8 with binary value
>> > 10100101, zero extending it to 64 bits via +^, applying a two's
>> > compliment, and then assigning bits [0:7] to another uint8 which at
>> that
>> > point contains the binary value of 01011010 (or hex value 0x5A).
>> > In your second example that isn't working, you're taking uint8 with
>> > binary value 10100101, zero extending it to 64 bits via +^, applying a
>> > two's compliment, and then displaying this *Int* (64 bits) as hex.[1]
>> > To turn it back you need to mask off bits [8:63] with: say ((+^$e) +&
>> > 0x0FF).base(16);" [2]
>> >
>> > [1] I'd show you the 64 bit value but it's a bunch of 1's followed by
>> > the value -0xA6.
>> > [2] Note, since the type has been promoted to an Int there' no going
>> > back to uint8 without an explicit assignment (afaik)
>> >
>>
>> That explains it. Thank you.
>>
>> I used uint8 to keep the ones to a mild torrent!
>>
>> If I am remembering correctly, 0xA5 going to 0x5A is
>> a ones compliment.
>>
>> What is the syntax for a twos complement anyway?
>
>
>>
>
> --
> __
>
> :(){ :|:& };:
>
Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
Looks like we have a different way of thinking, not to mention thinking about a particular idea. Obviously definitions and distinctions are only for those who care about them, and everyone else is free to ignore them so that there is no debate. Although if I'm not mistaken, it seems like we agree (minus perhaps my misunderstanding of how perl handles begin and end blocks, or bytecode..). G. -- Original Message -- Received: 08:32 AM EST, 12/10/2014 From: Aristotle Pagaltzis pagalt...@gmx.de To: perl6-users@perl.org Subject: Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?] * Parrot Raiser 1parr...@gmail.com [2014-12-07 22:40]: The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. Yes, surely that’s it. We all consider Python a compiler, after all. :-) Go on, tweak your definition to pin it down. :-) * Gerard ONeill oobl...@usa.net [2014-12-08 15:10]: How about an interpreter interprets input directly into action (even if there is some optimization going on), while a compiler converts instructions from one set to another set to be interpreted later. That’s just an unnecessarily concrete rephrasing of the definitions I mentioned. Which would make perl both at the perl source level, Perl never interprets raw perl code without first parsing it into an optree. and an interpreter at the bytecode level. Well yeah, bytecode always implies an interpreter. Thinking of execution as interpretation, this allows for the transmeta concept, where the CPU was just an interpreter / just in time compiler that interpreted x86 instructions. Although modern CISC CPU's have a step where the input to the chip was still converted to microcode which was actually what was run. So a compilation step, and an interpreting step. Execution takes a program as input and produces the program’s output as output. So it’s interpretation. By definition. Sometimes there are dedicated hard-wired circuits that do it, and sometimes there are other layers of abstraction around the hard-wired circuitry. The layers can be in hardware, and even then at different degrees of abstraction (FPGA vs microcode, say), or in software, and really what is software and what is hardware depends merely on your perspective. There are plenty of coprocessors that internally run code which is opaque from the outside; is that software or hardware? That’s what I meant by fuzzy ideas. You don’t get anywhere trying to nail this pudding to the wall. You only get somewhere if you accept that which is which is relative to your point of view and that the difference is defined in terms of the output: compilers transform programs to other programs and interpreters transform a program into its output. That’s it. E.g. if you have something perl running a Perl program then you have the CPU interpreting a program (perl) that itself interprets another program (the optree), which in turn was compiled from the user Perl program earlier on. Once you stop trying to artificially force everything into a single absolute distinction, the entire debate about which is which vanishes. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
How about an interpreter interprets input directly into action (even if there is some optimization going on), while a compiler converts instructions from one set to another set to be interpreted later. Which would make perl both at the perl source level, and an interpreter at the bytecode level. Thinking of execution as interpretation, this allows for the transmeta concept, where the CPU was just an interpreter / just in time compiler that interpreted x86 instructions. Although modern CISC CPU's have a step where the input to the chip was still converted to microcode which was actually what was run. So a compilation step, and an interpreting step. -- Original Message -- Received: 04:37 PM EST, 12/07/2014 From: Parrot Raiser 1parr...@gmail.com To: Aristotle Pagaltzis pagalt...@gmx.deCc: perl6-users@perl.org Subject: Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?] The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. The distinction mattered a lot more when compiling even a trivial program involved at least the order of minutes. Then, it was important to re-use the binary, to avoid recompiling for as long as possible. (Although even in the 1970s, a report-writer program could be run from source without noticeable delay.) Now, the compilation phase is usually trivial in comparison to run times, for any significant data set. Perl 6 just needs a spot of optimisation in the compile phase. :-)* On 12/6/14, Aristotle Pagaltzis pagalt...@gmx.de wrote: * Moritz Lenz mor...@faui2k3.org [2014-12-06 20:05]: First of all, the lines between interpreters and compilers a bit blurry. People think of Perl 5 as an interpreter, but actually it compilers to bytecode, which is then run by a runloop. So it has a compiler and an interpreter stage. This is sort of a tangent, but it was a clarifying insight that resolved a point of vagueness for me, so I’d like to just talk about that for a moment if you’ll indulge me. Namely, that line is actually very clear in a theoretical sense, if you judge these types of program by their outputs: Interpreter: A program that receives a program as input and produces the output of that program as output Compiler: A program that receives a program as input and produces another equivalent (in some sense) program as output Now some compilers emit programs that can be run directly by the CPU of the same computer that is running them, without an extra interpreter. This is what people with fuzzy ideas of the terms usually refer to when they speak of a compiler. But the output doesn’t have to be a program of this kind. The blurriness in practice comes from the fact that essentially all programming languages in use by humans are very impractical to use for direct interpretation. And so almost every interpreter ever written is actually coupled to a compiler that first transforms the user source program into some other form which is more convenient to interpret. Even the BASICs on those famous old home computers of the past are combined compiler-interpreters in this sense. Basically just parsing an input program up front as a whole essentially meets the definition of a compiler – even if a rather weak version of it. I think that means shells are typically true interpreters, and that they are more or less the only real examples of such. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
