Re: wxWidgets nativecall
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'
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'
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`