Re: Need sub for `LWP::UserAgent`
>> Hi All,
>>
>> I am trying to convert a p5 program to p6. What do I use in
>> place of `LWP::UserAgent`?
>>
>> I use it for downloading files from the web. I need to be able
>> to pass the following to the web page:
>>
>> Caller
>> Host
>> UserAgent
>> Referer
>> Cookies
>>
>> This is the p5 code I want to convert:
>>
>>http://vpaste.net/gtJgj
>>
>> Any words of wisdom?
>>
>> Many thanks,
>> -T
On 07/27/2017 10:30 PM, Gabor Szabo wrote:
LWP::Simple now allows you to set the header of your request.
See my recent article with examples: http://perl6maven.com/simple-web-client
I hope this helps.
regards
Gabor
On Fri, Jul 28, 2017 at 7:42 AM, Todd Chester wrote:
I see your article. I do believe this is what I want.
{
"args": {
"language": "Perl",
"math": "19+23=42",
"name": "Larry Wall"
},
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "LWP::Simple/0.090 Perl6/rakudo"
},
"origin": "17.19.208.37",
"url": "http://httpbin.org/get?name=Larry
Wall&language=Perl&math=19%2B23%3D42"
}
Questions:
1) may I leave off the `args` and only include the `headers`?
2) I need an example with headers. I have no clue what goes
before the first "{"
Many thanks,
-T
--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~
Re: Bi-directional communication with another process
Thanks Timo,
A Proc::Async example, after reading the doco. Agree, that't better, even
for the simple case :-)
- David
my $proc = Proc::Async.new('sh', '-c', 'for x in `seq 1 1` ; do echo
"o$x"; echo "e$x" 1>&2; done');
# subscribe to new output from out and err handles:
$proc.stdout.tap(-> $v { print "o:$v" }, quit => { say 'caught exception '
~ .^name });
$proc.stderr.tap(-> $v { print "e:$v" });
say "Starting...";
my $promise = $proc.start;
# wait for the external program to terminate
await $promise;
say "Done.";
On Fri, Jul 28, 2017 at 12:42 PM, Timo Paulssen wrote:
> We have Proc::Async which removes the need for the select call itself
>
Re: Need sub for `LWP::UserAgent`
LWP::Simple now allows you to set the header of your request. See my recent article with examples: http://perl6maven.com/simple-web-client I hope this helps. regards Gabor On Fri, Jul 28, 2017 at 7:42 AM, Todd Chester wrote: > Hi All, > > I am trying to convert a p5 program to p6. What do I use in > place of `LWP::UserAgent`? > > I use it for downloading files from the web. I need to be able > to pass the following to the web page: > >Caller >Host >UserAgent >Referer >Cookies > > This is the p5 code I want to convert: > > http://vpaste.net/gtJgj > > Any words of wisdom? > > Many thanks, > -T
Need sub for `LWP::UserAgent`
Hi All, I am trying to convert a p5 program to p6. What do I use in place of `LWP::UserAgent`? I use it for downloading files from the web. I need to be able to pass the following to the web page: Caller Host UserAgent Referer Cookies This is the p5 code I want to convert: http://vpaste.net/gtJgj Any words of wisdom? Many thanks, -T
Re: Bi-directional communication with another process
select() in this context is arguably a workaround for lack of threads,
although it can also be used to simulate threading ("green threads").
On Thu, Jul 27, 2017 at 8:41 PM, David Warring
wrote:
> Perl 5 and C have the select call that lets you determine which of a group
> of file-descriptor are ready for reading and writing. I thought it might be
> useful here.
>
> https://en.wikipedia.org/wiki/Select_(Unix)
>
> I've found a module by Tadzik, https://github.com/tadzik/IO-Select, but
> it's looking defunct and Parrot specifc.
>
> Are we missing a working 'select' call?
> - David
>
> On Fri, Jul 28, 2017 at 12:04 PM, Brandon Allbery
> wrote:
>
>> On Thu, Jul 27, 2017 at 7:49 PM, Norman Gaywood
>> wrote:
>>
>>> my $input = q:to/EOS/;
>>> line of text
>>> another line
>>> EOS
>>>
>>> my $cat = run 'cat', '-n', :in($input.print), :out;
>>> my $output = $cat.out.get;
>>> $cat.in.close;
>>> $cat.out.close;
>>>
>>> say "done";
>>> say $output;
>>>
>>> But that is not correct. I seem to be missing something.
>>>
>>
>> :in, :out, :err want a filehandle (or will create one if you specify
>> True, which is what pair syntax gives you if you specify one of them
>> without a filehandle). Not a string; and .print applied to a Str does not
>> turn the string into a filehandle, it sends the string to the filehandle in
>> $*OUT.
>>
>> my $cat = run 'cat', '-n', :in, :out;
>> $cat.in.print($input); # this .print, on IO::Handle, prints the string to
>> that handle
>> $cat.in.close;
>> my $output = $cat.out.slurp: :close;
>>
>> Note that you need to be very careful to avoid the "open3" deadlock:
>> pipes have limited buffers, and if you do this all in one thread when the
>> data is large enough to block on write, and the receiving program then
>> blocks on write back to you, you will deadlock. No language can protect you
>> from this. The solution is that either the writer or the reader (or both)
>> needs to be in its own thread so that if one blocks, the other can keep
>> running and eventually clear the block.
>>
>> --
>> brandon s allbery kf8nh sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: Bi-directional communication with another process
We have Proc::Async which removes the need for the select call itself
Re: Bi-directional communication with another process
Perl 5 and C have the select call that lets you determine which of a group of file-descriptor are ready for reading and writing. I thought it might be useful here. https://en.wikipedia.org/wiki/Select_(Unix) I've found a module by Tadzik, https://github.com/tadzik/IO-Select, but it's looking defunct and Parrot specifc. Are we missing a working 'select' call? - David On Fri, Jul 28, 2017 at 12:04 PM, Brandon Allbery wrote: > On Thu, Jul 27, 2017 at 7:49 PM, Norman Gaywood > wrote: > >> my $input = q:to/EOS/; >> line of text >> another line >> EOS >> >> my $cat = run 'cat', '-n', :in($input.print), :out; >> my $output = $cat.out.get; >> $cat.in.close; >> $cat.out.close; >> >> say "done"; >> say $output; >> >> But that is not correct. I seem to be missing something. >> > > :in, :out, :err want a filehandle (or will create one if you specify True, > which is what pair syntax gives you if you specify one of them without a > filehandle). Not a string; and .print applied to a Str does not turn the > string into a filehandle, it sends the string to the filehandle in $*OUT. > > my $cat = run 'cat', '-n', :in, :out; > $cat.in.print($input); # this .print, on IO::Handle, prints the string to > that handle > $cat.in.close; > my $output = $cat.out.slurp: :close; > > Note that you need to be very careful to avoid the "open3" deadlock: pipes > have limited buffers, and if you do this all in one thread when the data is > large enough to block on write, and the receiving program then blocks on > write back to you, you will deadlock. No language can protect you from > this. The solution is that either the writer or the reader (or both) needs > to be in its own thread so that if one blocks, the other can keep running > and eventually clear the block. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
Re: Bi-directional communication with another process
On Thu, Jul 27, 2017 at 7:49 PM, Norman Gaywood wrote: > my $input = q:to/EOS/; > line of text > another line > EOS > > my $cat = run 'cat', '-n', :in($input.print), :out; > my $output = $cat.out.get; > $cat.in.close; > $cat.out.close; > > say "done"; > say $output; > > But that is not correct. I seem to be missing something. > :in, :out, :err want a filehandle (or will create one if you specify True, which is what pair syntax gives you if you specify one of them without a filehandle). Not a string; and .print applied to a Str does not turn the string into a filehandle, it sends the string to the filehandle in $*OUT. my $cat = run 'cat', '-n', :in, :out; $cat.in.print($input); # this .print, on IO::Handle, prints the string to that handle $cat.in.close; my $output = $cat.out.slurp: :close; Note that you need to be very careful to avoid the "open3" deadlock: pipes have limited buffers, and if you do this all in one thread when the data is large enough to block on write, and the receiving program then blocks on write back to you, you will deadlock. No language can protect you from this. The solution is that either the writer or the reader (or both) needs to be in its own thread so that if one blocks, the other can keep running and eventually clear the block. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: Bi-directional communication with another process
You'll want to just pass :in and then use "$cat.in.print($input); $cat.in.close;" We just had a thread about this on reddit with zoffix and me weighing in: https://www.reddit.com/r/perl/comments/6pwqcy/how_do_i_interact_with_a_shell_program_using_perl/ On 07/28/2017 01:49 AM, Norman Gaywood wrote: > From inside a program I'd like to send some input to the stdin of > external program and read back the stdout. > > The example in https://docs.perl6.org/language/ipc under proc comes > close to what I want: > > my $echo = run 'echo', 'Hello, world', :out; > my $cat = run 'cat', '-n', :in($echo.out), :out; > say $cat.out.get; > $cat.out.close(); > > That works, however what I want however is a single external process, > sort of like: > > my $input = q:to/EOS/; > line of text > another line > EOS > > my $cat = run 'cat', '-n', :in($input.print), :out; > my $output = $cat.out.get; > $cat.in.close; > $cat.out.close; > > say "done"; > say $output; > > But that is not correct. I seem to be missing something. >
Bi-directional communication with another process
>From inside a program I'd like to send some input to the stdin of external program and read back the stdout. The example in https://docs.perl6.org/language/ipc under proc comes close to what I want: my $echo = run 'echo', 'Hello, world', :out; my $cat = run 'cat', '-n', :in($echo.out), :out; say $cat.out.get; $cat.out.close(); That works, however what I want however is a single external process, sort of like: my $input = q:to/EOS/; line of text another line EOS my $cat = run 'cat', '-n', :in($input.print), :out; my $output = $cat.out.get; $cat.in.close; $cat.out.close; say "done"; say $output; But that is not correct. I seem to be missing something.
Re: flatmap considered harmful?
I agree, that seems like pointless editorializing. If you can open a ticket at perl6/doc/issues on github, I'll remove that sentence this evening. (or someone can beat me to it.) On Thu, Jul 27, 2017 at 2:39 PM, Sean McAfee wrote: > While browsing the Perl 6 docs recently, here: > > https://docs.perl6.org/type/List#method_flatmap > > I noticed this paragraph for the first time: > >> It is considered bad practice to use flatmap. Instead of .flatmap( ), >> please use .map( ).flat as it is clear when the .flat is called and is not >> confusing like .flatmap. > > > To quote a certain president's lawyer: Says who? > > Flat-mapping is awesome; I've written code that does it in several different > programming languages, in none of which is it deprecated in this way. Is > there really any reason to avoid it in Perl 6 other than subjective notions > of how confusing it is? > -- Will "Coke" Coleda
flatmap considered harmful?
While browsing the Perl 6 docs recently, here: https://docs.perl6.org/type/List#method_flatmap I noticed this paragraph for the first time: It is considered *bad practice* to use flatmap. Instead of .flatmap( ), > please use .map( ).flat as it is clear when the .flat is called and is > not confusing like .flatmap. > To quote a certain president's lawyer: Says who? Flat-mapping is awesome; I've written code that does it in several different programming languages, in none of which is it deprecated in this way. Is there really any reason to avoid it in Perl 6 other than subjective notions of how confusing it is?
