Re: Bi-directional communication with another process

[David Warring]

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`

[Gabor Szabo]

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`

[Todd Chester]

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

[Brandon Allbery]

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

[Timo Paulssen]

We have Proc::Async which removes the need for the select call itself

Bi-directional communication with another process

[Norman Gaywood]

>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?

[Will Coleda]

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?

[Sean McAfee]

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?