Re: wxWidgets nativecall

2018-11-27 Thread Timo Paulssen
I haven't looked at wxwidgets with perl6, and the last time I used it
was with python many moons ago.

But I think the "AST converter" you're refering to is probably
App::GPTrixie - https://github.com/Skarsnik/gptrixie

If you have more questions, feel free to ask on the mailing list, or on
Stack Overflow, or real-time discussions on IRC, links can be found on
perl6.org

I haven't actually tried the C++ stuff in NativeCall, but we can surely
figure it out together :)

HTH
  - Timo

On 21/11/2018 03:31, Perry Sebastian wrote:
> Hi,
> I built an odd little application using wxPerl. The code worked ok,
> but I dislike the object interface and it does not mesh with P6. The
> big issue is that wxPerl gets built and tied to wxWidgets C++ code -
> the two are linked so you are basically stuck with that module to
> access wxWidgets. I have looked at NativeCall and some AST converter
> (can't seem to find it anymore). I'm not real thrilled about hacking C
> code, but I'm thinking that I might be able to NativeCall the wxWindow
> base class or wxFrame and then treat that as a P6 object - a windowing
> object. Any calls to window functions would have to use NativeCall,
> too, but the window object could accept roles and have async behaviors.
> Anyone else looking at this?
> Perry 


Re: How to use sub/method 'dir'

2018-11-27 Thread Brad Gilbert
On Mon, Nov 26, 2018 at 6:26 PM Trey Harris  wrote:
>
>
>
> On Mon, Nov 26, 2018 at 04:56 Fernando Santagata  
> wrote:
>>
>> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert  wrote:
>>>
>>> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
>>> is that it is passed strings.
>>
>>
>> Thank you!
>> I could have inferred that from the declaration of the 'test' argument here 
>> https://docs.perl6.org/routine/dir where the test is being done against '.' 
>> and '..', two strings:
>>
>>> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
>>> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>
>>
>> but I guess it's a long stretch.
>> Maybe a note in the docs would be useful to others.
>>
>>>
>>> I would argue that inside of the `test` that `$*CWD` should be set to
>>> `a`, and/or the values should be IO objects.
>>> (They are going to become IO objects eventually anyway.)
>>
>>
>> Indeed I think that even tough one can do any kind of test on the 
>> directory's content, the most usual ones are those using the file test 
>> operators, so defaulting to IO is probably more useful than defaulting to 
>> Str.
>
>
> I'm not sure that's true. I think it's a question of following the Principle 
> of Least Surprise.

Exactly, the way it works right now is surprising (to new Perl 6 programmers).

It even took me a few seconds to realize what the problem was, and
I've been learning Perl 6 for about a decade.

> The only substantive difference between `my $i = "foobar".IO` and `my $s = 
> "foobar"` besides needing to stick the `.IO` in when you want to do IO-y 
> things with `$s` is that `$i` retains the knowledge of $*CWD at the time of 
> instantiation. But `dir` always returns paths that stringify _relative to 
> `$*CWD` at the time of the `dir` call._ Notice the difference between 
> `$i.gist` (which, if evaluated, will not consistently re-create the original 
> object) and `$i.perl` (which will):
>
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix), 
> :CWD("/home/trey/perl6/rakudo-star"))
> > chdir "/tmp"
> "/tmp".IO
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix), 
> :CWD("/home/trey/perl6/rakudo-star"))
>
> The string, OTOH, is also relative to the `$*CWD` at the time of the `dir()` 
> call, but if you call `.IO` on it after changing directories, the path object 
> is interpreted relative to the new directory. This is unsurprising; what 
> _would be_ surprising is if a string changed as a result of external program 
> state.

I was only talking about the object within the `:test` argument of the
`dir` call.

The resulting sequence wouldn't change at all.

> Large-scale file-munging operations have always been squarely in Perl's 
> wheelhouse, and doing fancy operations with complex subtrees (such as 
> syncing, normalizing, archiving, collating, etc.) are common.

Precisely why I suggested changing it.
The way it works now is harder to use than it could be.

> The string doesn't offer as much in the way of features, but I think it 
> behaves much more predictably when doing these sorts of operations. If you 
> `chdir $dest` after the `dir` but before doing your munging, then you must 
> remember to prepend the old working directory if you need to access the 
> original file (i.e., `$src = $*CWD;  for @files -> $f { $src.add($f) ... }`), 
> while the new files would just be `$f`. If you don't change directories, then 
> you must say `$dest.add($f)` to refer to the new files, while the old file is 
> just `$f`. But in either case, it's unsurprising and predictable.

Actually Str behaves less predictably than an IO object for the `test` argument.
If you want to compare it stringwise, do so and it works:

my $dir = IO::Path( 'b', :CWD('a'.IO) );

say $dir eq 'b'; # True

If you want to see if it is a directory, just ask it:

say $dir.d; # True

`.gist` doesn't stringify an object, it returns enough information for
a human to be able to figure out what the object is.

When you do stringy operations on an IO::Path object (or any object),
it calls the `.Str` method not `.gist`.
The only things which implicitly call `.gist` is `say` and `note`.

Now what I proposed was having the CWD set to the directory being
examined inside of `test`, which is a different `CWD` than the result
of the `dir` call.

> say dir('a'):test( {temp $*CWD = 'a'.IO; .IO.d && .IO ~~ none(<. ..>)} )
("a/b".IO)
> say dir('a', :test( {temp $*CWD = 'a'.IO; .IO.d && .IO ~~
none(<. ..>)} ))».CWD
(/home/brad)

Note that `none(<. ..>)` still worked just fine against such an
object. (the default `:test` argument)

I also didn't say they had to be IO objects, just that the CWD should
be inside of the directory of the dir being tested within the `:test`
argument.

>
> If, OTOH, these were IO objects, if you changed directories, you'd think from 
> the gist that you'd do the same. And if you don't 

Re: How to use sub/method 'dir'

2018-11-27 Thread Fernando Santagata
I can only argue that since the function's name 'dir' reminds a shell level
command, and 'ls a' and 'dir a' work in a certain way, I was expecting that
the function 'dir' worked in the same way, following the Principle of Least
Surprise :-)

On Tue, Nov 27, 2018 at 1:37 AM Trey Harris  wrote:

>
> On Mon, Nov 26, 2018 at 19:26 Trey Harris  wrote:
>
>>
>>
>> On Mon, Nov 26, 2018 at 04:56 Fernando Santagata <
>> nando.santag...@gmail.com> wrote:
>>
>>> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert  wrote:
>>>
 The reason `dir('a', test => { .IO.d })` doesn't work like you expect
 is that it is passed strings.

>>>
>>> Thank you!
>>> I could have inferred that from the declaration of the 'test' argument
>>> here https://docs.perl6.org/routine/dir where the test is being done
>>> against '.' and '..', two strings:
>>>
>>> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
 method dir(IO::Path:D: Mu :$test = none('.', '..'))

>>>
>>> but I guess it's a long stretch.
>>> Maybe a note in the docs would be useful to others.
>>>
>>>
 I would argue that inside of the `test` that `$*CWD` should be set to
 `a`, and/or the values should be IO objects.
 (They are going to become IO objects eventually anyway.)

>>>
>>> Indeed I think that even tough one can do any kind of test on the
>>> directory's content, the most usual ones are those using the file test
>>> operators, so defaulting to IO is probably more useful than defaulting to
>>> Str.
>>>
>>
>> I'm not sure that's true. I think it's a question of following the
>> Principle of Least Surprise.
>>
>> The only substantive difference between `my $i = "foobar".IO` and `my $s
>> = "foobar"` besides needing to stick the `.IO` in when you want to do IO-y
>> things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
>> instantiation. But `dir` always returns paths that stringify _relative to
>> `$*CWD` at the time of the `dir` call._ Notice the difference between
>> `$i.gist` (which, if evaluated, will not consistently re-create the
>> original object) and `$i.perl` (which will):
>>
>> > $f.gist
>> "foobar".IO
>> > $i.perl
>> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
>> :CWD("/home/trey/perl6/rakudo-star"))
>> > chdir "/tmp"
>> "/tmp".IO
>> > $f.gist
>> "foobar".IO
>> > $i.perl
>> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
>> :CWD("/home/trey/perl6/rakudo-star"))
>>
>
> Oops, ignore the changing variable names here; I was copying lines from a
> REPL session where I'd used `$f`, and then I changed `$f` to match `$i` in
> the text before it and didn't fully complete the renaming. It's just a
> single variable.
>
>
>> The string, OTOH, is also relative to the `$*CWD` at the time of the
>> `dir()` call, but if you call `.IO` on it after changing directories, the
>> path object is interpreted relative to the new directory. This is
>> unsurprising; what _would be_ surprising is if a string changed as a result
>> of external program state.
>>
>> Large-scale file-munging operations have always been squarely in Perl's
>> wheelhouse, and doing fancy operations with complex subtrees (such as
>> syncing, normalizing, archiving, collating, etc.) are common.
>>
>> The string doesn't offer as much in the way of features, but I think it
>> behaves much more predictably when doing these sorts of operations. If you
>> `chdir $dest` after the `dir` but before doing your munging, then you must
>> remember to prepend the old working directory if you need to access the
>> original file (i.e., `$src = $*CWD;  for @files -> $f { $src.add($f) ...
>> }`), while the new files would just be `$f`. If you don't change
>> directories, then you must say `$dest.add($f)` to refer to the new files,
>> while the old file is just `$f`. But in either case, it's unsurprising and
>> predictable.
>>
>> If, OTOH, these were IO objects, if you changed directories, you'd think
>> from the gist that you'd do the same. And if you don't change directories,
>> you _could_ do the same (`$dest = "/destdir".IO; $dest.add($f)` works using
>> the gist). But if you do change directories, it's now the _old file_ that's
>> just `$f`; the new file becomes `$*CWD.add($f)`. This feels quite strange
>> and surprising to me.
>>
>> The very slight keystroke-saving convenience of not requiring the outputs
>> of `dir` to be followed with `.IO` before doing IO operations on individual
>> IO objects in-place doesn't seem worth the strangeness of their behavior
>> when doing bulk operations on them from a distance.
>>
>> (I was thinking through possible have-your-cake-and-eat-it-too solutions
>> like `.gist` and `.path` of IO objects created from strings changing their
>> string representation if and only if you changed working directories and
>> these all seem to just Waterbed Complexify the problem elsewhere. Perhaps
>> someone can come up with an everybody-wins solution—but except for moving
>> the filetest operations into `Cool`