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

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

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:

Re: Verifiable Releases/The Build System is Ridiculous

I apologize if there was any tone to my post, the only place I intended there to be any was when I pointed out the --no-check-certificates flag. Please understand Perl 6 is the second or third language I have found that does not secure its ecosystem. The number of non-language projects which

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

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

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

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

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;

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,

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

Re: Verifiable Releases/The Build System is Ridiculous

Quoting R0b0t1 : Are there any releases signed by the developers? The official releases located at https://rakudo.perl6.org/downloads/star/ do not seem to have signatures available. There's Rakudo the compiler and Rakudo Star distribution which is the compiler + docs + some

Re: Verifiable Releases/The Build System is Ridiculous

On 27 July 2017 at 09:13, R0b0t1 wrote: > Are there any releases signed by the developers? The official releases > located at https://rakudo.perl6.org/downloads/star/ do not seem to > have signatures available. Can you be more specific about the technologies you suggest and the

Re: Verifiable Releases/The Build System is Ridiculous

The details of how to use the star GitHub repository are in tools/star/release_guide.pod . You're entirely welcome to create a bundling that has a better build system than what Rakudo Star uses -- indeed, Rakudo Star has always been intended to be just one of many possible bundlings of Rakudo

Your posting is a bit unfortunate

Hi Robot, Understanding your points, correlating them to past decisions, calling up what the decisions actually were and their reasons, finding out which of these reasons were good and which were bad - that's already a pretty taxing task. Now if you start out with a dismissive attitude such

Verifiable Releases/The Build System is Ridiculous

Are there any releases signed by the developers? The official releases located at https://rakudo.perl6.org/downloads/star/ do not seem to have signatures available. As a stopgap measure I attempted to clone https://github.com/rakudo/star and run Configure.pl. I felt it strange that it warned me

Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

It’s really in the dispatch within Cool. Note the difference between: for ^1 { 1.match(/1/) } and: for ^1 { "1".match(/1/) } I’m afraid this is really uncovering a basic dispatch caching issue. I have tried a few things, but I’m afraid this is really an issue inside

Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

It’s really in the dispatch within Cool. Note the difference between: for ^1 { 1.match(/1/) } and: for ^1 { "1".match(/1/) } I’m afraid this is really uncovering a basic dispatch caching issue. I have tried a few things, but I’m afraid this is really an issue inside

[perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

Oh! You're totally right! Then, it's not as bad as it looks. In fact, this commit actually *improved* the case when it has to match Str-s (more than 2x speedup). So perhaps the slowdown is not so critical. After all, how often do people match thousands of Ints… On 2017-07-26 23:55:21,

Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

Looking at the profile of (^1).grep({!/1/}).elems.say the first 5 entries (responsible for 70% of CPU in that example) have nothing to do with matching, but everything with trying to find the right dispatchee. And it looks like this is basically caused by: $_ = 1; /1/ Because $_

Re: [perl #131805] [REGRESSION] [PERF] .grep-ing with a code block is now almost twice slower ( .grep({/foo/}) )

Looking at the profile of (^1).grep({!/1/}).elems.say the first 5 entries (responsible for 70% of CPU in that example) have nothing to do with matching, but everything with trying to find the right dispatchee. And it looks like this is basically caused by: $_ = 1; /1/ Because $_