Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-12-29

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

All times shown according to UTC.

Time Nick Message
01:51 willthechill joined #perl11
01:52 willthechill mako93r: I'm here, but in a meeting right now
02:15 mako93r That's ok. Stay with your meeting. Don't care we can talk later. No big deal
02:15 mako93r Hope I can handle it
03:32 willthechill joined #perl11
06:25 bpmedley joined #perl11
09:23 anton joined #perl11
11:04 anton_p joined #perl11
14:16 travis-ci perl11/cperl#2076 (smoke/master - 2cba5c9 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/187460724
16:14 mako93r joined #perl11
16:15 mako93r howdy
16:34 willthechill mako93r: hey hey
16:34 willthechill you were asking about astyle?
16:35 mako93r yes, why are the options '--keep-one-line-blocks' and '--keep-one-line-statements' used?
16:36 willthechill because otherwise astyle goes crazy with putting every little thing on it's own newline
16:37 willthechill it will even put single characters on a new line
16:37 willthechill stupid
16:37 willthechill then our hard-coded example code would have to look stupid too, in order to match astyle's generated output
16:37 willthechill and one of the things about RPerl which we should be most proud (or thankful at least) is that RPerl's generated output code looks very very nice
16:38 willthechill it is not crazy machine-generated-spaghetti like many other automatic-code-generation systems may produce
16:38 willthechill on the contrary, our RPerl input code and the generated C++ output code look almost identical, and both are very well-formatted and easily-read by humans
16:38 willthechill does that answer your question?
16:39 mako93r ok, but isn't the reference file processed by astyle, too?
16:42 mako93r I just stumbled upon this because the options mentioned caused errors under OpenBSD when I ran 't/13'
16:42 mako93r the astyle version there (1.21.1) doesn't know them
16:43 willthechill wow that is an old version of astyle
16:44 willthechill what BSD machine are you using?
16:44 mako93r OpenBSD 6.0 (amd64) under VMWare
16:44 mako93r 2 CPUs
16:45 willthechill Artistic Style 1.21  (June 2007)
16:45 mako93r yep, that's it
16:46 mako93r I will have to install astyle from source
16:46 mako93r not a big issue
16:47 mako93r but without that old version I wouldn't have noticed this
16:47 willthechill yeah good point
16:47 willthechill I guess BSD is just not very much up-to-date!  :-P
16:48 mako93r depends on the BSD in use
16:48 willthechill are you installing astyle 2.06, which was just released a few days ago?
16:49 mako93r yes, I'm going to use that
16:50 mako93r but not today :-D
16:50 mako93r I saw so much 'make test' and compiling
16:51 mako93r when start dreaming about it you definitly need a break and should do something else :-D
16:52 willthechill mako93r: true!  :-)
16:53 willthechill mako93r: software release update...  we will release RPerl v2.4 in 3 days from now on Jan 1
16:53 willthechill now that we have released CloudForFree.org v1.0 as our Christmas gift!
16:54 mako93r super cool, can't await it :-)
16:55 willthechill well, you are PART of it, because I am very hopeful that we can solve this darn AppVeyor issue in time for v2.4 release
16:56 willthechill is has never ceased to be important that we get AppVeyor properly working, even though we both had to take a short break
16:57 willthechill in fact, it is critical, because AppVeyor is one of our blocking tasks which must be completed before the next big phase of RPerl development
16:57 mako93r yeah, it was annoying long enough
16:58 mako93r now I can concentrate far better on operator implementation
16:59 mako93r but I'm not which one should come next
16:59 willthechill mako93r: okay I'm confused, I thought we have not yet finished with AppVeyor?!?
16:59 willthechill you have made a temporary hack env var to skip a bunch of astyle tests in AppVeyor?
17:00 mako93r yes, I wanted to know whether there are other issue or not
17:00 mako93r I'm still on this diff problem
17:02 willthechill sorry I'm still confused, you were just talking about going back to work on operator implementations?
17:02 willthechill but yet we are not yet finished with the astyle diff check problem in AppVeyor?
17:10 willthechill astyle min version check added to RPerl installer:  https://github.com/wbraswell/rperl/blob/master/script/rperl_installer.sh#L432-L433
17:15 mako93r AppVeyor is finished in sense of it can be used now but not finished in sense of it is complete
17:15 mako93r that operator stuff is only stuff I have in mind
17:16 willthechill okay what "operator" stuff are we talking about?
17:16 willthechill you mean creating new RPerl operators like push, pop, etc?
17:17 mako93r I have CPPOPS in mind
17:17 willthechill okay yes so you are talking about creating new RPerl operators
17:18 willthechill unfortunately, it is not good to leave such a hack in place on the AppVeyor issue
17:18 willthechill normally I would not have accepted such a pull request, except I thought you were still moving forward with finishing AppVeyor
17:19 willthechill in fact, the pull request broke Linux builds, I had to modify it to allow for normal Linux, which is not a problem because I already fixed it, but it does point to the fact that we only have a temporary hack in place, not a real solution
17:20 mako93r I don't like this situation, too
17:20 willthechill I expect this is all going to be fixed by something quite simple with astyle, such as "one missing astyle switch" or the like
17:21 mako93r the problem is astyle works fine under my Windows
17:21 willthechill okay well I keep asking if you have logged directly into the AppVeyor VM to run astyle for real and test the output?
17:22 willthechill I assume the answer is no, because that should lead us to a solution
17:22 willthechill in other words, run astyle in your own Windows, then run it on AppVeyor VM, and compare output side-by-side
17:22 willthechill should have a solution immediately!
17:22 willthechill or at least, should know what the problem is immediatley
17:23 willthechill anything other than logging directly into AppVeyor VM is not the right solution, I think
17:25 mako93r ok, I will do that
17:28 willthechill great, let me know how I can help on the Linux side of things!  :-)
17:29 mako93r I will run astyle without the '-q' switch
17:30 mako93r maybe this gives me some extra information
17:30 willthechill good idea!
17:33 mako93r first I will run AppVeyor (my AppVeyor) see what it gives me
17:33 mako93r after that I will rerun it and login remotely
17:33 willthechill okay good
17:34 willthechill I also have another question about the appveyor.yml, but I will wait on that
17:34 willthechill one thing at a time!
17:34 mako93r no you can ask now
17:35 willthechill well bulk88 says that AppVeyor does not properly read from appveyor.yml files, which is why we had to set a long single-line test command sequence in the main AppVeyor account
17:36 willthechill however you have created a new appveyor.yml file
17:36 willthechill so there is obviously some conflict of information, or somebody is mistake, or I'm confused, etc?
17:38 mako93r could be but I had no issues with appveyor.yml if it would be otherwise your AppVeyor wouldn't work
17:39 willthechill okay, so do you have a long test command sequence in your AppVeyor account, like in the main AppVeyor account?
17:45 mako93r no, you can consider the appveyor.yml a dump of my AppVeyor configuration
17:46 mako93r because it's exactly that
17:46 mako93r nothing hand-written
17:47 willthechill okay then I am definitely confused about this potential conflict or overlap between the appveyor.yml file and the long single-line test command sequence
17:51 travis-ci RPerl build passed. Will Braswell says 'RPerl Installer, Section 25, AStyle Minimum Version Requirement'
17:51 travis-ci https://travis-ci.org/wbraswell/rperl/builds/187507220 https://github.com/wbraswell/rperl/compare/63a4a1508fc7...769db0eecaae
17:55 mako93r me too I've never heard about AppVeyor not processing its yml-file properly
17:56 willthechill okay we will wait for bulk88 to come give his input
17:59 mako93r good, let's stay with this for now I'll write you about my progress when I know something new
17:59 willthechill sounds good!  :-)
18:34 bulk88 i guess ill have ot comment later
20:46 travis-ci perl11/cperl#2077 (smoke/master - a0db114 : H.Merijn Brand): The build passed. https://travis-ci.org/perl11/cperl/builds/187546132
21:43 travis-ci perl11/cperl#2078 (smoke/master - 74bcb39 : Father Chrysostomos): The build passed. https://travis-ci.org/perl11/cperl/builds/187557283
21:49 mako93r joined #perl11
21:52 mako93r bad news: I reran AppVeyor without astyle being installed, and you know what? same issue, same errors, no difference
21:52 mako93r astyle doesn't seem to be the suspect
21:52 willthechill hmm okay
21:53 mako93r have to dig deeper
21:53 willthechill it is possible that you would see the same errors even if astyle WAS the culprit
21:53 willthechill it is possible that simply removing astyle causes the same errors as misconfigured or misbehaving astyle
21:54 willthechill BUT you could be right!
21:54 willthechill I'm just throwing it out there
21:54 willthechill :-)
21:58 mako93r now I know I shouldn't have promised to take care of this problem but this is what you get when you accept the challenge to cope with a windows environment :-D
21:59 mako93r becoming a doctor is easier
21:59 willthechill haha good one!
22:00 willthechill bulk88 and I have fixed approximately 100 Windows bugs before this, so you are actually quite lucky
22:00 willthechill (I lost count)
22:00 willthechill but yes, your point is still valid!
22:00 willthechill Windows is very hard to use
22:01 willthechill thankfully, once AppVeyor is truly fixed, then it will make our Windows job somewhat easier
22:01 willthechill at least we only have to go through this ONCE in order to get AppVeyor working properly!  :-D
22:01 mako93r but promise is promise I won't give up and don't try to count Windows errors (even a 64bit integer would be to appropriate data type :-D)
22:02 mako93r would NOT be that si
22:02 willthechill we have already done some work on the Windows data types
22:02 willthechill so hopefully that part will not cause you any problems
22:02 mako93r very googd
22:02 willthechill I definitely appreciate your fighting spirit!
22:05 bulk88 xxx /n vs /r/n problem?
22:05 mako93r That's required when dancing with a dragon! And compiler stuff is always about dancing with a dragon. It has good reasons why 'Compilers, Principles, Techniques and Tools' is called the dragon book.
22:05 bulk88 wild guess
22:06 willthechill bulk88: are you saying that our previous attempt at utilizing an appveyor.yml file failed due to a DOS-vs-UNIX newline character mismatch, and that the current success with the appveyor.yml file is because we unknowingly side-stepped the newline problem this time?
22:07 mako93r bulk88: my guess too but the errors are not happening under my Windows
22:09 mako93r bulk88: if you are right could this issue be caused by a git config?
22:11 bulk88 I've never fully understood git's line ending covnersion on windows
22:12 bulk88 its either "always to windows" for editing and back to unix for commits, or "binary" mode
22:12 bulk88 its confusing
22:13 bulk88 if your repo has a CRLF file, and you are in "always to windows" mode, I think the commit box every time tries to commit the unix version resulting in 100% of lines being different
22:13 willthechill wow that sounds bad
22:13 bulk88 mixed line ending files are even funner to deal with
22:15 bulk88 I remember some of the msys/unix tools for windows like patch.exe crash if you give then LF files instead of CRLF because they use MS libc which only sees CRLF
22:15 bulk88 something like that
22:15 willthechill sheesh
22:17 willthechill okay well at this point we have BOTH the appveyor.yml and the test command sequence enabled on the main AppVeyor account!
22:17 willthechill that's probably not right
22:17 willthechill here's the command sequence:
22:17 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
22:17 willthechill and here's the appveyor.yml:
22:17 willthechill https://github.com/wbraswell/rperl/blob/master/appveyor.yml
22:18 willthechill bulk88 & mako93r: what do we need to do here?
22:21 mako93r stay with the appveyor.yml but keep the command sequence that's not a problem because it's overriden by appveyor.yml
22:23 willthechill mako93r: no we don't want both
22:23 willthechill we want 1 solution, not 2 overlapping half solutions
22:23 willthechill that's why I just pasted all the info so you can compare the 2
22:30 mako93r you can delete the command sequence of the main appveyor if you wish because appveyor.yml does all the work I just thought to save the cmdline of AppVeyor in case of we need it later
22:37 willthechill yes, that is why I wanted you to please triple-check and make sure the appveyor.yml does in fact do 100% of the things contained in the test command sequence?
22:37 willthechill (if answer is yes, then I will delete command sequence and save a copy of it)
22:42 mako93r YES IT DOES ABSOLUTLY! I just want you to save this cmdline in some txt file maybe in a directory named 'legacy' or 'attic' just in case I'm wrong (I'm only human you know)
22:44 willthechill I want to save the command sequence inside appveyor.yml as a comment
22:44 willthechill what is the proper way to make a comment?
22:44 mako93r that should be possible, checking...
22:45 willthechill it will be a comment containing a ton of special characters
22:46 mako93r wikipedia says: Comments begin with the number sign (#), can start anywhere on a line and continue until the end of the line. Comments must be separated from other tokens by white space characters.[13] If they appear inside of a string, then they are number sign (#) literals.
22:47 mako93r as far as I can see you can do this without problems
22:48 willthechill mako93r: I just remembered that ingy is one of the creators of yml
22:48 willthechill haha!
22:48 mako93r oh, really? what a coincedence :-D
22:49 mako93r so we stay with the yml approach?
22:49 willthechill yes, a coincidence...  OR IS IT?!?  *bum-bum-buuuuummmmm*  haha
22:49 willthechill yes yml is good
22:49 willthechill I will do it now
22:50 mako93r Excellent! Now only one solution, like you wanted.
22:55 bulk88 did anyone even try an d run https://github.com/wbraswell/rperl/blob/master/appveyor.yml ? the env vars arent carriied line ot line, reini just has the appveyor.yml call a .bat file
22:55 bulk88 for cperl
22:58 mako93r bulk88: do you use powershell or cmd?
23:00 willthechill ugh AppVeyor bug, if you cancel a build at the wrong point, it will not let you restart it
23:00 willthechill "Build version 1.0.292 already exists. Update next build number or change version format."
23:00 willthechill I just disabled the test sequence on AppVeyor, but will have to recommit something to make it rebuild
23:01 willthechill so we should know shortly if this works with only appveyor.yml or not
23:05 willthechill mako93r: actually no I don't think this is an AppVeyor bug at all, I think it is caused by appveyor.yml!
23:05 willthechill I just recommitted a small change, now I get this:
23:05 willthechill "Build version 1.0.292 already existed and a random string was appended to its version to avoid collision. Update next build number or change version format."
23:05 willthechill I notice the "v1.0.X" format there is the same as contained w/in the appveyor.yml file
23:06 willthechill so in other words, once I disabled the AppVeyor test command sequence, now I get an error and can't build
23:13 mako93r line 3 'do_not_increment_build_number: true' set it to 'do_not_increment_build_number: false'
23:14 willthechill done, testing now
23:15 willthechill okay at least the build is starting this time!  :-)
23:15 mako93r hope that helps
23:16 mako93r otherwise I would be out of options
23:16 willthechill it's downloading chocolatey now
23:16 willthechill so it's doing something!
23:16 mako93r cool
23:17 mako93r if that works appveyor.yml needs to be adjusted
23:18 mako93r usually 'do_not_increment_build_number: false' is the default
23:18 mako93r not 'do_not_increment_build_number: true' like it is in my config
23:20 willthechill okay it is running tests now!
23:20 willthechill t/04 successfully so far
23:20 willthechill so far so good
23:21 mako93r ok, is there a way I can have a look on this too?
23:22 willthechill you can try!   https://ci.appveyor.com/project/wbraswell/rperl
23:28 mako93r ok, looks good 't/12' and 't/13' running, will take some time
23:29 willthechill good deal
23:38 travis-ci RPerl build passed. Will Braswell says 'Windows, AppVeyor Tests, Save Test Command Sequence For Future Reference'
23:38 travis-ci https://travis-ci.org/wbraswell/rperl/builds/187579347 https://github.com/wbraswell/rperl/compare/769db0eecaae...64d319407cd8
23:46 mako93r looks good
23:46 mako93r AppVeyor, too
23:49 mako93r willthechill: summary: we learned astyle is not the culprit, appveyor.yml is for now the way to go, and I could get you to modify your rperl installer
23:50 willthechill yes AppVeyor looks good without the test command sequence
23:50 willthechill bulk88: AppVeyor is now passing w/ the test command sequence disabled and the appveyor.yml enabled
23:50 willthechill mako93r: good work so far!  :-)
23:51 willthechill mako93r: I should reiterate, it may be possible for astyle to still be the culprit
23:53 mako93r cool, I'd like to have it that way because I'm not in the mood to commit, change, modify, or whatever else anymore
23:53 mako93r need to get some sleep
23:53 mako93r cu

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