Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-08-19

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
06:04 bulk88 joined #perl11
06:53 anton joined #perl11
10:21 mako joined #perl11
11:30 mako joined #perl11
11:42 mako Interesting, bulk88 already knows this issue: http://www.gossamer-threads.com/lists/perl/porters/316876
13:27 mako joined #perl11
14:41 willthechill mako: checking
14:42 willthechill bulk88: for some reason I thought this try() catch() issue was solved during our work at YAPC::NA in Orlando???
15:13 bulk88 I took some trys at YAPCNA at fixing it, but ultimately C++ exceptions just dont work for some reason I couldnt figure out, the windows C++ exception handler code from the OS goes in an infinit loop using 100% and isn't able to unwind the frame
15:13 bulk88 100% CPU
15:14 willthechill bulk88: yes I remember that we were not able to actually fix the underlying issue
15:15 willthechill but I thought we properly disabled all offending tests for Windows?
15:15 bulk88 the only tests disabled were GMP
15:17 willthechill dang I guess you're right!
15:18 willthechill bulk88: do you suggest we simply to a check for "Win32" OS like we did for GMP, and disable all offending throws_ok() calls in Windows?
15:18 bulk88 no
15:18 willthechill okay?
15:18 bulk88 remember rperl passes on certain permutations of strawbeerry perl
15:19 bulk88 32 bit only
15:20 willthechill yes
15:20 willthechill right
15:20 willthechill except now we are freezing at t/04 on appveyor
15:20 willthechill and mako is having the same freeze
15:20 willthechill so I don't know how to proceed?
15:40 mako joined #perl11
16:31 mako joined #perl11
17:20 mako joined #perl11
17:24 mako willthechill: A really though problem. I'm thinking about it. No matter what solution we will come up with I can tell you this is gonna be though.
17:25 willthechill bulk88: how should mako and I proceed?
17:25 mako Maybe implementing our own Exception Handling?
17:25 willthechill no that's too complicated
17:25 willthechill this is not a problem we created, we just need to work around it
17:26 mako If we can.
17:26 willthechill let's see what bulk says
17:28 mako hm, ok.
17:29 bulk88 a C++ compiler without C++ exceptions means you contact that c++ compielr vender
17:29 bulk88 that exception loop bug has to be rewritten in a plain C++ way somehow and submitte
17:29 bulk88 d
17:29 willthechill okay
17:30 willthechill so what info do we need to collect in order to exactly identify which compilers are at fault?
17:30 willthechill I guess we are only experiencing this in Windows, as a start?
17:31 bulk88 64b only
17:31 bulk88 I dotn remember which strawbeery (and therefore which mingw GCC version) the 64b bug was on
17:31 bulk88 afk
17:31 willthechill okay
17:33 willthechill mako: since you have a live platform which shows this bug, then what we need to do is as bulk said, create a pure-C++ example of this problem occurring, where we do not have any Perl code involved at all
17:33 willthechill that way, we can send that pure-C++ example code to the appropriate compiler devs and hopefully they can help us fix it.
17:57 mako Ok, I'm thinking about how to do this at best.
17:58 willthechill excellent
17:58 willthechill tell me when you are ready for me to test it on Linux, in theory it should NOT hang in Linux or in some Windows environments
17:58 mako But till than (because this will take some time) how to handle the appveyor stuff?
17:59 willthechill we won't know how to approach appveyor until we know exactly what is causing this crash and what platforms are affected
18:00 willthechill then we can hopefully configure appveyor to use a non-hanging setup somehow
18:00 willthechill so for right this minute, just leave appveyor as it is
18:01 mako Ok, so appveyor will fail for the near next time (no big issue I guess, at least for now)?
18:02 willthechill yes we will allow appveyor to continue failing for a short while, until we know what is the C++ cause of this issue
18:02 willthechill sorry I can't be more help, but this issue does not exist in Linux!  :-P
18:04 mako As long as travis passes we are not in hell, I guess. Leave the Windows issues to others, Will. We will find a way. No matter how hard, absurd, weird, or whatever.
18:04 willthechill haha true!
18:04 willthechill as long as travis passes, then at least I know it "works"
18:05 willthechill yes I will need to rely on you guys for anything that is outside of Linux
18:05 mako Wait!!! There's something left I would tell you. Let me think for a moment...
18:05 willthechill okay
18:07 mako Ahhhhh, yes this: I could make RPerl running on OpenBSD 5.9 with G++ 4.9.3
18:07 mako Most of t/*.t passed
18:07 mako hello world example compiled
18:07 willthechill wow sweet!
18:07 willthechill is there any way to set up an automated BSD testing, like we have with travis and appveyor?
18:09 willthechill *away from computer for a while*
18:09 mako I had to take a somewhat adventurous way to achieve a result. Please consider this as experimental.
18:10 mako It's not even ready for an elaborated test suite.
18:13 mako But when it's time for an automated BSD testing consider me as the expert of choice (like bulk88 for Windows).
18:18 mako Just this: I put my bib in the Windows stuff because Win is the main OS I'm using on on my computer.
18:21 mako main development I do is on OpenBSD and other BSDs. But every BSD on a Virtual Machine. I'm too lazy and silken to install BSD on physical hardware (my computer that is).
18:28 mako Anyway, consider every BSD stuff as experimental. Even though I developed 'Operator01NamedExp & Operator10NamedUnaryLog
18:28 mako ' on it.
18:29 mako I've never mentioned this till today.
18:43 mako joined #perl11
20:07 willthechill mako: well that is good info!  :-)
20:10 bulk88 willthechill appveyor hangs because of a bug in dmake
20:10 bulk88 appveyor uses 32b strawberry
20:12 willthechill bulk88: okay thank you, that is very important info as well!
20:13 willthechill bulk88: so you are saying that appveyor is NOT hanging due to throws_ok()?
20:13 bulk88 correct
20:13 willthechill okay and what is the dmake bug?
20:13 bulk88 dmake when launched from inline::C hangs with 0% CPU IIRC
20:13 bulk88 but only under the appveyor process
20:14 bulk88 something about how stdout/stderr is captured by the appveyor proc hangs dmake
20:14 bulk88 IDK what it is
20:14 bulk88 I've considered patching the strawberry perl to use gmake in the build and test receipie
20:14 willthechill okay well I'm open to whatever can unbreak appveyor!
20:15 willthechill what can I do to move this appveyor issue forward?
20:48 mako joined #perl11
20:51 willthechill mako: have you tried logging into appveyor yet, while an RPerl job is live and running?
20:51 mako willthechill: What about breaking with appveyor completely? Travis is the standard!!!!!
20:51 willthechill mako: no you are confused
20:51 willthechill appveyor is for windows
20:51 willthechill travis is for linux
20:51 willthechill totally different
20:52 willthechill mako: I think if you can get as far as being logged into appveyor and seeing the remote Windows desktop on your own computer, then you might be able to start helping bulk88 to fix appveyor
20:53 willthechill mako: hopefully you saw bulk88's comments above, stating that the appveyor bug is in dmake, which is different than your throws_ok() bug?
21:00 mako ok.
21:00 willthechill mako: every time you make a pull request it fires up appveyor automatically
21:01 willthechill so just make a pull request which you believe should work without any errors
21:01 mako ok, but what about disabling appveyor temporarily?
21:02 willthechill um no, we are in the process of fixing appveyor
21:02 willthechill disabling it goes against that goal
21:03 willthechill anyway, once you make a pull request, then you should be able to see it here:
21:03 willthechill https://ci.appveyor.com/project/wbraswell/rperl/build
21:05 mako Your link, I've got a 'Not found' reply.
21:06 willthechill oops sorry, just delete the "build"
21:06 willthechill https://ci.appveyor.com/project/wbraswell/rperl
21:12 mako Something else about appveyor: Do you have a choice when it comes to choosing perl version, c++ compiler, c++ compiler version, you name it?
21:12 willthechill yes
21:13 willthechill that is set by a custom startup script
21:13 mako Ok, what choices are you given?
21:13 willthechill which you can see in blue text as lines 7, 8, and 9 in the latest appveyor link
21:13 willthechill no choices
21:13 willthechill custom hard-coding
21:13 willthechill bulk88 hard-coded the custom start-up script commands
21:13 willthechill lines 7, 8, 9
21:14 willthechill OH WAIT
21:14 willthechill sorry I'm wrong
21:14 willthechill only line 9
21:14 willthechill lines 7 and 8 are automated by appveyor
21:14 willthechill to connect w/ github
21:14 willthechill only line 9 is our custom startup line
21:14 willthechill and you only get 1 line I guess, which is why we have a bunch of commands separated by &&
21:15 willthechill this is our custom setup:
21:15 willthechill choco install strawberryperl --forceX86 && set PATH=C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\windows\system32;C:\windows; && gcc -v && g++ -v && perl -V && dmake -V || perl Makefile.PL && perl -e"require CPAN;CPAN::Shell->notest('install','App::cpanminus');" && cpanm -n -v --installdeps . & set RPERL_DEBUG=1 && set RPERL_VERBOSE=1 && dmake test
21:17 mako only line 9 under control? I am not amused.
21:18 willthechill well when you invent and launch a free global windows test cloud, then you can add more lines
21:18 willthechill but for now, we are stuck with appveyor
21:18 willthechill and we only need 1 line anyway
21:18 willthechill thanks to &&
21:18 willthechill it may be ugly, but it simply works
21:18 mako ok
21:18 willthechill kinda like high magic Perl!  hahaha  :P
21:18 mako :-)
21:19 willthechill notice that RPERL_DEBUG and RPERL_VERBOSE
21:19 willthechill are currently turned on in appveyor
21:19 willthechill so you can use those messages to debug
21:19 mako good to see
21:20 willthechill yes  :-)
21:23 mako Wouldn't it be nice (at least for now) that all RPerl-Sys-Devs would agree with one and exactly one (and no other) OS, Developing Environment, you name it  and developing RPerl only on that.
21:24 mako And add portability stuff (other compilers and OSs) later?
21:24 mako This is reasonable.
21:25 mako Because you wouldn't consider RPerl a "simple" piece of software.
21:26 mako Image how far you would have come without the portability stuff. Think about it how annoying this can be.
21:27 mako I can imaging that you've got better ideas how to your time.
21:29 mako (correction last post)I can imagine that you've got better ideas how to spend your spare time.
21:33 mako improving & developing & researching RPerl for example
21:34 willthechill mako: you're about 3 years too late for that, my friend
21:34 willthechill that was how we operated in the beginning
21:34 willthechill but once you have users then you can't just say "we only work on Will's computer"
21:34 willthechill so now that we are at RPerl v2.0 then we need to take ourselves seriously and have real portability
21:35 mako Seems so.
21:35 willthechill anyway, I leave 75% of the portability work to you
21:36 willthechill because I only use Xubuntu v16.04.1
21:36 willthechill so anything different than that must, by definition, be tested by someone (or something) else
21:36 mako Like me :-D
21:37 willthechill yes!
21:37 willthechill correct  :-)
21:39 mako Nice I could winkled out something more out of you. What version of perl and g++ are you using? Directly asking in this case.
21:40 willthechill gcc v5.4.0 & perl v5.22.1
21:40 willthechill both standard in Xubuntu v16.04.1
21:41 willthechill well, I THINK both are standard, I did an `apt-get upgrade` after installing
21:41 willthechill but close either way
21:49 mako gcc v4.9.3 & perl v5.20.2 (+patches stated by OpenBSD team (OpenBSD 5.9))
21:51 willthechill that should be fine, as you know gcc min version is v4.7
21:51 willthechill and perl works back through v5.10 so far
21:51 willthechill it may be possible to make it work w/ v5.8 or even v5.6, but I will probably leave that to someone else if they must have it, unless it becomes business-critical in the future
21:52 mako On OpenBSD 5.9: the mentioned perl version is system standard, gcc version installed (4.9.3) via package system (system standard of gcc is 4.2.1)
21:52 willthechill oh boy yes that's an old gcc alright, haha!  :-P
21:52 willthechill many systems still have ancient perl and gcc installed
21:53 willthechill I know there are still big shops which are on perl v5.6
21:53 willthechill somewhere out there
21:54 mako Yeah, and that's only the simple story. My story of making RPerl run on OpenBSD:
21:54 mako Installing all the dependencies (Perl Modules).  --ok
21:56 mako Installing g++ v4.9.3 via package system. --ok (libgmp included)
21:57 mako Didn't get (and still don't get) how to install 'Inline::CPP' right.
21:57 mako Not a big issue on OBSD.
22:00 mako Modified 'Inline/CPP/Config.pm'  --  'our $compiler = g++ ...'
22:01 mako So 'g++' looks like 'eg++' in 'Inline/CPP/Config.pm'
22:03 mako After that I tried to compile 'lib/RPerl/Learning/Chapter1/exercise_1-hello_world.pl'
22:05 mako Had to mention the real C++ compiler to 'script/rperl' via '--CXX=´which eg++`'
22:05 mako But after that it worked. Very nice.
22:06 willthechill okay good!
22:06 willthechill now you need to update https://github.com/wbraswell/rperl/blob/master/INSTALL
22:07 willthechill with OpenBSD specific instructions
22:07 willthechill ;-)
22:12 mako Mr. Burns says: EXCELLENT, Smithers!!! :-D
22:12 willthechill haha good ol' Burnsie
22:16 mako !!!Release the dogs!!!    Everybody, no matter the circumstances, wishes to say this at least once in live.
22:17 mako Yes, I will update.
22:17 willthechill haha "release the hounds, Smithers"
22:18 willthechill and Homer says "the dogs, and the bees, and the dogs who have bees in their mouths so when they bark they shoot bees at you"  :-P
22:19 mako But again OBSD in particular and BSD in general is still experimental stuff. (Label it under "Coming soon").
22:19 mako Bee Dog.
22:20 mako Sounds like the name of the next upcoming Hip-Hop-Star. :-D
22:20 willthechill lol you funny
22:20 willthechill and yes Windows is also experimental
22:21 willthechill and Mac too I guess, I know rurban tried it a while back but I don't know who has tried Mac lately
22:32 mako Mac? Ah, Mac is some sort of BSD (at least some kernel parts). It's worth a try. But is it worth it? Different story. I made my experiences. I don't regret. Your decision!
22:34 willthechill we must support all platforms
22:34 willthechill RPerl must work on any platform that Perl works on, and more!
22:34 willthechill because in pure CPPOPS_CPPTYPES mode, we will eventually be able to run without any Perl or perl.h whatsoever
22:35 willthechill which means that someday we can support platforms which do not have Perl installed
22:38 mako Reasonable, from my point of view. Otherwise the value of RPerl would be lowered.
22:39 mako One advantage of RPerl should be to create CPP-code with ease and without bothering. That's it!!!
22:40 willthechill yes very true
22:44 mako I did enough CPP (even C++11) and I know how annoying the low level stuff can get. This 21st century guys. It's to be done in a new way. RPerl is to be the future.
22:45 mako Speedy time. :-D
22:47 willthechill yes so true, so true!!!
22:47 willthechill amen, haha
22:49 mako And it shall be. But to put it mildly: A long, stony road before us. We need to hit it. Everything in live has its price.
22:50 mako Hit the road, guys and girls!
22:50 willthechill yes we are on step 2 of a long journey
22:50 willthechill (step 2 == v2.0)
23:03 mako Let's hope that step 3 is not too far away. (But now it is). BTW: What should be done for RPerl? The most important stuff, that is.
23:08 willthechill most important thing is operators and new tests
23:08 willthechill I have to do the tests
23:08 willthechill so you can do the ops
23:09 willthechill :-)
23:09 willthechill v3.0 will be released July 4, 2017
23:11 mako Independance day. Very good.
23:11 mako I will handle this sh*t.
23:11 mako :-D
23:15 willthechill haha good use of self-censoring
23:21 mako If everything fails you can use October the 3. German Unification Day. Has at least the same carry than Independance day
23:22 mako Even though the meaning is very different.
23:23 willthechill haha yes well we have already set our permanent release schedule
23:24 willthechill v1.0 on July 4, 2015
23:24 willthechill v2.0 on July 4, 2016
23:24 willthechill v3.0 on July 4, 2017
23:24 willthechill and so forth
23:24 willthechill forever and ever, amen
23:24 willthechill thus said The Voice In The Wilderness
23:24 willthechill ;-)
23:24 willthechill and now I must go perform a juggling show!
23:24 willthechill so I will be gone for several hours
23:24 willthechill good luck everyone!  (especially me, haha)
23:32 mako May the 4th be with you, Captain!
23:33 mako Or, May it? :-D
23:46 mako Your tests, passing they have to. :-D
23:54 mako master yoghurt says: Have to come first, your tests, that is. His ambitions great, they are. Had not coped enough, yet.

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary