Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-07-15

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

All times shown according to UTC.

Time Nick Message
00:00 bulk88 on C stack
00:00 bulk88 https://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx
00:00 bulk88 %lld is the proper ISO size in theory
00:09 bulk88 av_store(people, (I32)i, newSVpvf("Jeffy Ten! %lld/%lld CPPOPS_PERLTYPES", i, (integer)(SvIV(my_size) - 1)));
00:09 bulk88 that also passes for me
02:14 willthechill bulk88: okay well the question is, will %lld always pass with all the different 'integer' typedefs?
02:15 willthechill https://github.com/wbraswell/rperl/blob/master/lib/RPerl/DataType/Integer.h#L12-L38
02:36 willthechill bulk88: the answer seems to be "no", we can not just use %lld for all the different integer typedefs
02:36 willthechill http://stackoverflow.com/questions/2424528/printf-of-a-size-t-variable-with-lld-ld-and-d-type-identifiers
02:53 willthechill bulk88: are you familiar with the inttypes.h macros like PRIi8?
02:54 willthechill http://stackoverflow.com/questions/13052880/format-specifier-of-int8-data-type-in-c
02:55 willthechill http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/inttypes.h.html
03:43 bulk88 inttypes.h doesnt exist in VC 2010, and "doesnt exist" in "visual c" according to google
03:44 bulk88 i dotn have access to my VC 2013 laptop right now
03:44 willthechill ah I was afraid of that
03:46 willthechill #if defined(WIN32) && !defined(PRId64 ) \n #define PRId64 "I64d" \n #endif
03:46 bulk88 perl uses IVdf not PRId64 or PRId32
03:46 bulk88 where is that?
03:46 willthechill that is a solution from near the top of here:  http://stackoverflow.com/questions/6299083/cross-platform-printing-of-64-bit-integers-with-printf
03:47 bulk88 but remmeber make sure you have a 64 bit in perl int he first place
03:47 bulk88 your %ld code was technically truncating to 32 bits all the printf numebrs but it wasnt visible
03:47 willthechill did you look at all the new typedefs yet?   https://github.com/wbraswell/rperl/blob/master/lib/RPerl/DataType/Integer.h#L12-L38
03:48 bulk88 if your "integer" typedef is dynamic sized to 32/64 then your format string flag has to also be dynamically size
03:48 bulk88 d
03:48 willthechill yes I believe you are correct
03:48 bulk88 you wont find a perl with 8 or 16 bit IV
03:49 bulk88 IDk why you use the integer type isntead of using perl's IV ytpe all over the place
03:49 willthechill I will leave the 8-bit and 16-bit integer typedefs in there, in case people want to manually use the g++ compiler -D flag to set the types and try to save a little memory
03:50 bulk88 ok
03:50 willthechill integer is a C native type, so it is used by CPPOPS_CPPTYPES mode in RPerl
03:50 willthechill IV is a Perl native type, so it is used by CPPOPS_PERLTYPES mode in RPerl
03:50 willthechill that's kinda basic and important
03:50 willthechill 2 totally different RPerl modes
03:51 bulk88 i just fix the pie crust, I dont want to know what is in the pie lol
03:51 willthechill well there you go
03:51 willthechill have a cherry
03:51 willthechill ;)
03:52 willthechill PERLOPS_PERLTYPES = 1x speed
03:53 willthechill CPPOPS_PERLTYPES = ~10x speed
03:53 willthechill CPPOPS_CPPTYPES = ~200x - 400x speed
03:53 willthechill so yeah
03:54 willthechill for this particular bug, here are the 3 modes:
03:54 willthechill PERLOPS_PERLTYPES   https://github.com/wbraswell/rperl/blob/master/lib/RPerl/DataStructure/Array/SubTypes.pm#L533-L547
03:55 willthechill CPPOPS_PERLTYPES   https://github.com/wbraswell/rperl/blob/master/lib/RPerl/DataStructure/Array.cpp#L795-L808
03:55 willthechill CPPOPS_CPPTYPES    https://github.com/wbraswell/rperl/blob/master/lib/RPerl/DataStructure/Array.cpp#L867-L878
03:57 willthechill is defined(WIN32) a real thing in all Windows OSs?
03:58 bulk88 yes
03:58 willthechill okay great!  :-)
03:58 willthechill next question: since there is an I64d format code in Windows, does that mean there are also I8d and I16d and I32d and I128d format codes in Windows as well?
03:58 bulk88 actually no
03:59 willthechill "no" to which question?
03:59 bulk88 _WIN32 is MS's define, WIN32 is perl's define
03:59 willthechill oh okay
03:59 willthechill so can I safely use _WIN32 always and forever, and just ignore WIN32?
04:00 bulk88 perl core uses WIN32 everywhere
04:01 bulk88 you can use WIN32, _WIN32 is only if you are writing perl unawaare, no perl headers included and no EUMM C code
04:02 bulk88 I128d isnt implemented on Windows
04:02 bulk88 thearetically it could exist one day
04:03 willthechill right now we are still including perl.h and linking against libperl, but in the future I plan to cut out all Perl dependencies in CPPOPS_CPPTYPES mode to decrease the size of the binaries at the very least
04:03 willthechill so I want to start being "perl unaware" in CPPOPS_CPPTYPES mode now
04:03 willthechill as much as possible, at least
04:04 bulk88 use _WIN32 then
04:04 willthechill okay great
04:04 willthechill so _WIN32 will always work?
04:04 bulk88 yes
04:04 willthechill sweet!  :-D
04:04 willthechill as for I128d, I understand that it may exist in the future
04:05 willthechill for now, what do you use for 128-bit integer format code?
04:06 bulk88 rumor says %I128d
04:07 bulk88 no ISO standard for it yet
04:07 willthechill okay then I will just use %I128d and we can change it later if needed
04:08 bulk88 someone else online invented %llld as a joke
04:09 willthechill LOL that's a good one!
04:09 willthechill I assume that is not real?
04:10 bulk88 you dont know what the ISO commissionw ill aprove
04:12 willthechill good point, could be anything!
04:13 willthechill okay I'm going to implement the "semi-dynamic" integer format codes along with the semi-dynamic integer typedefs
04:13 willthechill I will ping you (hopefully shortly) when I have it up on github
04:25 willthechill bulk88: question... on Windows platforms that DO have the macro PRId64 defined, would it be coming from inttypes.h like in Linux?  or would it originate from somewhere else?
04:28 bulk88 its available in PP in Config.pm  on all platforms, C wise its only from inttypes.h I think
04:28 bulk88 I dont know teh full answer im grepping perl src to find out
04:30 willthechill okay my "real" question is: if _WIN32 is defined, then how do I know if PRId64 is defined w/out first doing #include <inttypes.h>  ???
04:30 willthechill and if inttypes.h does not exist on user X's Windows OS, then we will get a compiler error instead of working
04:30 willthechill so I've got kindof a chicken-and-egg problem
04:31 bulk88 tricky question
04:31 willthechill PRId64 is (in theory) defined in inttypes.h, but I don't know how to test if #include <inttypes.h> will fail
04:31 bulk88 GCC for win32 has inttypes.h
04:31 bulk88 VC fopr win32 is unknown, probably not
04:32 bulk88 $Config{d_PRId64} always, on all win32 compilers, has the correct flag
04:32 bulk88 "ld or ""I64f"
04:32 bulk88 correction "I64D"\
04:32 willthechill OH so you are saying I can do the logic in Perl always safely, then pass it on to C?
04:32 bulk88 yes
04:33 bulk88 look at d_PRId64 in config_heavy.pl
04:33 willthechill okay that is different than the all-C-preprocessor solution I am trying to do
04:33 bulk88 the all c proprocessor solution is special casing VC
04:34 willthechill yes but I can't figure out how to actually implement the all-preprocessor solution, due to the chicken-and-egg problem of how-to-know-if-inttypes.h-exists
04:35 bulk88 im about to fall asleep but I greped up https://metacpan.org/source/INGY/Git-XS-0.02/xs/libgit2/include/git2/inttypes.h#L78
04:35 bulk88 #ifdef _MSC_VER
04:36 bulk88 #define PRId64 "I64d"
04:36 bulk88 #endif
04:36 bulk88 actually
04:36 bulk88 #ifdef _MSC_VER
04:36 bulk88 #define PRId64 "I64d"
04:36 bulk88 #else
04:36 bulk88 #include "inttypes.h"
04:36 bulk88 #endif
04:37 willthechill okay so on Windows, always use I64d and never include inttypes.h
04:37 willthechill on not-Windows, always include inttypes.h and use PRId64
04:37 bulk88 https://blogs.msdn.microsoft.com/vcblog/2013/06/27/whats-new-for-visual-c-developers-in-vs2013-preview/ UH OH
04:37 bulk88 they added it for Vc 2013
04:38 bulk88 inttypes.h
04:38 bulk88 until I am home, I cant give you an answer
04:38 willthechill okay so how do we know if we have inttypes.h in Windows?
04:38 bulk88 if its VC 2013 or newer
04:38 willthechill and how do we test for VC13 or newere?
04:39 bulk88 http://stackoverflow.com/questions/70013/how-to-detect-if-im-compiling-code-with-visual-studio-2008 with >= operator
04:39 willthechill so check (_MSC_VER >= 1800)
04:40 bulk88 yes
04:40 willthechill okay so I CAN and SHOULD do the all-preprocessor solution
04:41 bulk88 18 is the internal/actual version number of the MS C compiler, version was from Microsoft C compiler 1.0 from 1982
04:41 bulk88 the current Visual C is the source code descendent of the 1982 version
04:41 willthechill cool history
04:41 willthechill ;-)
04:42 willthechill so am I assuming that if _WIN32 is defined but _MSC_VER is not defined, then I am using something like cygwin or strawberry in Windows, and thus I can always safely do include <inttypes.h>  ?
04:42 bulk88 correct, in that permutation its a GCC of some kind
04:42 willthechill okay so in Windows, it is _only_ VC earlier than 2013 that does not have inttypes.h?
04:42 bulk88 correct
04:43 willthechill great, so I can do the all-preprocessor solution
04:43 bulk88 I cant test the code until im home tho
04:43 bulk88 on VC I mean
04:43 willthechill gotcha
04:43 willthechill are you out of town for multiple days, or are you just out for the evening and getting back home tonight?
04:46 willthechill I will proceed with the all-preprocessor solution
05:12 willthechill bulk88: can I just ignore _WIN32 completely, since _MSC_VER will only be defined on Windows platforms, so testing defined(_MSC_VER) implies defined(_WIN32) ?
05:16 willthechill here's what I've got for 64-bit:
05:16 willthechill #   if defined(_MSC_VER) && (_MSC_VER < 1800)  // MS Visual Studio older-than-2013
05:16 willthechill #define INTEGER "I64d"
05:16 willthechill #   else  // non-Windows, Windows w/ GCC, or MS Visual Studio 2013-or-newer
05:16 willthechill #include <inttypes.h>
05:16 willthechill #define INTEGER "PRId64"
05:16 willthechill #   endif
05:17 willthechill I am using "INTEGER" as the name of the formatting code
06:38 willthechill bulk88: okay the new code is on github and appears to be working for Linux at least, should be ready for you to test on Windows w/ GCC, Windows w/ MSVC < 2013, and Windows w/ MSVC >= 2013
06:39 willthechill FYI, here is the new preprocessor-based format code solution:    https://github.com/wbraswell/rperl/blob/master/lib/RPerl/DataType/Integer.h#L11-L101
06:39 willthechill and here is the line of code which was causing the test failure before, you can see %ld is replaced w/ %"INTEGER"    https://github.com/wbraswell/rperl/blob/master/lib/RPerl/DataStructure/Array.cpp#L804
06:40 willthechill I have also replaced %ld and %lld everywhere else in the RPerl code base wherever rperltypes.h has been included, which is pretty much everywhere
06:41 willthechill the only place where %ld should remain is hand-coded testing stuff, as well as t/02 and t/03 which need to use %ld because they do not include rperltypes.h
07:33 travis-ci RPerl build passed. Will Braswell says 'Tests, C++ Generate, Part 17'
07:33 travis-ci https://travis-ci.org/wbraswell/rperl/builds/144928359 https://github.com/wbraswell/rperl/compare/f4cf65f59191...ee1a7fa9b58d
07:34 willthechill yay
08:23 willthechill bulk88: on appveyor we have all tests passing until t/09, at which point is hangs or freezes while calling waitpid on the very first of it's 162 test input files
08:23 willthechill https://ci.appveyor.com/project/wbraswell/rperl/build/1.0.156
08:24 willthechill assuming you see this message after a delay, then I assume you will want to reinitialize the appveyor build so that you can remotely log into the Windows VM and discover why it is hanging on waitpid
08:24 willthechill because this is now beyond my abilities
08:24 willthechill :-)
08:32 travis-ci RPerl build canceled. Will Braswell says 'Tests, Interpret Execute, Add Progress Messages'
08:32 travis-ci https://travis-ci.org/wbraswell/rperl/builds/144937499 https://github.com/wbraswell/rperl/compare/ee1a7fa9b58d...0046b5223864
08:33 willthechill that's fine
08:33 willthechill it passed
08:52 travis-ci RPerl build passed. Will Braswell says 'Tests, Interpret Execute, Enable Debugging Messages For Windows OS'
08:52 travis-ci https://travis-ci.org/wbraswell/rperl/builds/144940894 https://github.com/wbraswell/rperl/compare/0046b5223864...721f24076300
08:54 willthechill yay
10:00 ashevchuk joined #perl11
12:00 mako joined #perl11
12:31 punter joined #perl11
13:39 lizmat joined #perl11
17:07 punter joined #perl11
18:52 willthechill joined #perl11
18:54 Topic for #perl11 is now Perl5 + Perl6 == Perl11; # http://irclog.perlgeek.de/perl11/
18:54 willthechill okay, didn't know I could change the topic so easily, hopefully that didn't actually CHANGE it!
18:54 willthechill bulk88: howdy!  :-)
18:58 bulk88 13.t is the only test file that fails now  http://paste.scsys.co.uk/527148
18:58 bulk88 on SHA-1: 721f240763005f884b6975f2c5f251a33c44f2cb
18:58 bulk88 * Tests, Interpret Execute, Enable Debugging Messages For Windows OS
18:59 willthechill this is in MSVS?
18:59 willthechill what version?
18:59 bulk88 strawberry 32 bit 5.20
18:59 willthechill ah okay gotcha
18:59 willthechill looks like I need to update the absolute-path-trimming code
19:00 willthechill it is allowing your "C:\sources\rperl\blib\lib/" path to exist
19:00 willthechill when it should be deleted
19:00 willthechill we want to generate this:    #include "RPerl/Algorithm.h"
19:00 willthechill but instead we are generating this:    #include "C:\sources\rperl\blib\lib/RPerl/Algorithm.h"
19:01 willthechill is there any reason why it would not work correctly using #include "RPerl/Algorithm.h" on your system?
19:01 bulk88 IDK where the code is
19:02 bulk88 there was commit "* Windows OS, Interpret Execute Test, Fix Absolute Path Handling" and that GH PR I filed
19:03 bulk88 maybe its something to do with $RPerl::INCLUDE_PATH
19:03 willthechill here is the code:   https://github.com/wbraswell/rperl/blob/master/lib/RPerl/Compiler.pm#L864-L879
19:04 willthechill it is the subroutine post_processor__absolute_path_delete()
19:04 willthechill in RPerl::Compiler
19:04 willthechill there are 2 commented-out debugging lines in that sub
19:05 willthechill please uncomment them and let us know what it says
19:05 willthechill that should give us a clue at least!  :-)
19:06 bulk88 afk
19:20 mako joined #perl11
19:20 mako joined #perl11
19:33 willthechill mako: please grab the latest github code and give it a test!  :-)
19:33 willthechill in Windows
19:33 willthechill :P
20:50 mako willthechill: I'm on it. Did a 'git pull'. Overlooked the changes. Looks good. Sorry but I am somewhat busy today. This will take some time till I will give you an answer.
20:51 willthechill mako: okay sounds good, thanks!  :-)
20:57 mako BTW: I'm preparing my rperl assignment so I can become an official contributor (a matter of at most 1 week). And I'm doing experiments to make RPerl running on OpenBSD (a matter of whatever time it needs). Happy Weekend!
20:57 willthechill wow that sounds great!
20:57 willthechill mako++
20:57 willthechill :-D
20:58 mako :-D
21:03 mako At least the basic stuff is running. RPerl 2.0 on OpenBSD 5.9. But It's still not ready. I've installed from BSD's ports and packages the 'g++' package (version 4.9.3). I will send you a msg when I'm able to compile a simple 'hello world'
21:05 willthechill sweet
21:05 willthechill good deal!
21:05 willthechill once you are approved as an official author, then you can edit the INSTALL file with info for BSD
21:08 mako Not that easy at the moment. The issue could be with RPerl but it's more likely there's some issue with 'Inline::CPP'. But I'm not sure. My main goal now is to learn about the most important dependencies RPerl is relying on. (like Inline::CPP, PadWalker, and Parse::Eyapp)
21:09 willthechill Yes especially Inline::CPP & Parse::Eyapp
21:09 willthechill PadWalker is used but not nearly as much as the other 2
21:13 mako Inline::CPP & Parse::Eyapp, 2 of the most essential modules RPerl is using as dependencies. It would be to complicated to develop RPerl without 'em. (Perl's syntax is stuff that's hard to cope with)
21:14 willthechill It would be "nearly impossible" to create RPerl w/out I::CPP & P::Eyapp
21:15 willthechill or at least "add 5 or 10 years of work"
21:17 mako So what do you think. A beginning RPerl system developer must know Inline::CPP and Parse::Eyapp? And Module::Scandeps, too (even though it's a different part of the game)?
21:18 willthechill No not necessarily, I have abstracted away most of that stuff so that new RPerl system devs don't need to know it
21:19 willthechill the starting point for all RPerl system devs should be to create several RPerl operators
21:19 willthechill and that does not require any real knowledge of any RPerl dependencies
21:19 willthechill fortunately!
21:20 willthechill Knowledge of Inline::CPP is needed for adding new advanced RPerl-to-C++ binding features
21:20 willthechill definitely not for new RPerl system devs
21:20 willthechill knowledge of Parse::Eyapp is needed for changing the RPerl grammar
21:20 willthechill also DEFINITELY not for new RPerl system devs!
21:20 willthechill this is good because it means the barrier to entry is not so high, the learning curve for new RPerl system devs is not so steep
21:33 mako willthechill: I had a look at 'Module::Scandeps
21:33 mako I saw code like this:
21:33 mako if (/^package\s+(\w+)/) {             $CurrentPackage = $1;             $CurrentPackage =~ s{::}{/}g;             return;         }
21:35 mako What do you think? Isn't the 's{::}{/}g' somewhat useless?
21:38 bulk88 willthechill look at the slashes http://i64.tinypic.com/1z36vd3.png
21:38 bulk88 thats form 13.t
21:38 bulk88 *from
21:39 mako Ok, not an issue related to RPerl, but who knows? It's an RPerl dependency, so maybe it could be an issue.
21:42 willthechill bulk88: checking now
21:42 willthechill mako: hang on just a minute, sorry for the delay
21:44 willthechill bulk88: that link loaded about 3 million ads and 0 actual image for me to view
21:45 willthechill it forwarded me to here    http://tinypic.com/view.php?pic=1z36vd3&amp;s=9#.V4lZb99vGgQ
21:45 willthechill it is some kind of spam hole
21:46 willthechill bulk88: in other words, I can not view the image
21:46 bulk88 do you have a better imagehost to suggest?
21:47 willthechill I am not against tinypic but it is simply not working for me
21:47 willthechill mako: don't worry about Module::Scandeps, we are in no way responsible for what is inside that module
21:49 willthechill mako: the only modules which we have any control over are Parse::Eyapp (I now own it), Inline::Filters (rurban now owns it on my behalf), and Inline::* (ingy and davido own them, we talk in #inline and I submit patches when possible)
21:50 willthechill bulk88: when you load    http://i64.tinypic.com/1z36vd3.png    does it forward you here    http://tinypic.com/view.php?pic=1z36vd3&amp;s=9#.V4lZb99vGgQ    ???
21:50 willthechill bulk88: because I literally can not see any image except for ads
21:51 bulk88 yes
21:52 bulk88 pic is on right side
21:52 willthechill okay well can you copy the actual image URL and send me that please?
21:52 willthechill like, right-click on the image in your browser and "open image in new tab" or "copy image URL"
21:52 bulk88 doesn't work that way with tinypic
21:52 bulk88 if the referrer isn't tinypic is redirects to the full pag with ads
21:53 willthechill oh I see    http://oi64.tinypic.com/1z36vd3.jpg
21:53 willthechill geez that's annoying
21:53 willthechill next time let's just post the direct jpg link
21:53 willthechill notice how they fool you with a link that looks like a png image
21:53 willthechill but it is not a real image
21:53 willthechill it forwards you to a spam site
21:53 willthechill tsk tsk
21:53 willthechill ANYWAY now I can see the image
21:54 willthechill at the jpg link
21:54 willthechill :-P
21:54 mako willthechill: Excellent! Good to know. I'm finished for today. Good night, good fight, guys
21:54 willthechill mako: goodnight my friend!
21:54 willthechill bulk88: I see the slashes are reversed
21:54 willthechill so we need to match on either-slash
21:54 bulk88 http://imgur.com/BetuMI1
21:55 willthechill yes imgur.com seems to be much easier to deal with
21:55 willthechill I did not get trapped or tricked by imgur like with tinypic
21:55 willthechill :-)
21:56 willthechill bulk88: so anyway, I will fix that issue with the slashes now, will let you know shortly when it is fixed
21:56 bulk88 sometimes my adblock gets an ad script into an infinite loop querying ads from the adserver because the target ad can't be loaded
21:56 bulk88 yes
21:57 bulk88 oi64 as server name doesnt help
21:57 willthechill good deal
21:57 willthechill yes that is "overloaded integer, 64-bit", right?  ;-)
21:57 willthechill just kidding!
22:00 mako One thing before I can sleep I need to one thing: Does anybody of you guys have read the dragon book 'Compilers Second Edition Principles, Techniques, & Tools
22:01 mako I'm just curious. Before I go sleeping.
22:02 willthechill mako: yes we used it in school, I have not read it cover-to-cover like a novel but it is a good reference book to have on the shelf
22:02 willthechill thankfully the GCC team has done much of the dragon work for us
22:05 mako To put it simply: Nobody of us (including me) has ever entered the dragon? Not that this has to be an issue?
22:07 willthechill If you are asking if I have ever contributed code to the GCC compiler, then the answer is no.
22:07 willthechill And I hope I never have to do so.
22:07 willthechill rurban is the man for binary programming.
22:07 willthechill He is a low-level compiler expert.
22:07 willthechill But he is not online right now.
22:08 willthechill bulk88 also knows alot about low-level compiler stuff in Windows.
22:16 mako left #perl11
22:48 willthechill bulk88: okay the latest code fix is up on github
22:52 willthechill hopefully it works this time!  X-D
23:00 bulk88 "low-level compiler stuff in Windows." A B::C binary takes 1-2 hours to compile (VC process runs for 1-2 hours), when I randomly hit pause in the C debugger on the VC proc, it was inside a func called HashTblKillDeadBits, i guess the hash table isn't operating like a hash
23:01 willthechill haha well then!
23:02 willthechill bulk88: meanwhile, I am hoping my latest code makes tests pass on your strawberry
23:02 willthechill and it still freezes on appveyor in waitpid   https://ci.appveyor.com/project/wbraswell/rperl/build/1.0.157
23:02 willthechill in t/09
23:27 travis-ci RPerl build passed. Will Braswell says 'Windows OS, Handle Backslashes In Absolute Paths'
23:27 travis-ci https://travis-ci.org/wbraswell/rperl/builds/145135966 https://github.com/wbraswell/rperl/compare/721f24076300...d9c48f682daf
23:29 willthechill yay

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