Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2013-12-03

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

All times shown according to UTC.

Time Nick Message
00:11 rurban1 joined #perl11
00:27 bulk88 RPerl on strawberry Perl 5.16, failed http://pastie.org/private/nrellzq2cua6ucl39r8og
00:28 mirjam joined #perl11
00:29 ingy joined #perl11
00:56 Will_the_Chill bulk88: looks easy to step past that issue with the prescribed "-std=c++0x or -std=gnu++0x" options
00:56 Will_the_Chill gonna be AFK for a few hrs
01:19 mirjam joined #perl11
01:45 mirjam joined #perl11
03:07 bulk88 joined #perl11
03:34 mirjam joined #perl11
03:41 mirjam joined #perl11
04:24 mirjam joined #perl11
04:25 bulk88 "[19:55] <Will_the_Chill> bulk88: looks easy to step past that issue with the prescribed "-std=c++0x or -std=gnu++0x" options" the problem with that is, I can't do it (well, I can, but keep reading), if you want a CPAN smoker (which is not a human) to pass, you have to add that in RPerl as necessery (I'm not defining that)
04:27 Will_the_Chill bulk88: oh yes, you're absolutely correct.  I was thinking more along the lines of "tell me where to add the options in RPerl and I will do it".  :)
04:27 bulk88 I hate Inline::C, I prefer xsubpp and EU::MM toolchains
04:29 bulk88 mainly because I know how to do it in EU::MM https://github.com/bulk88/perl5-win32-api/commit/1beef44666ba58eb7b332db7d3a3d401a2f145d7#diff-d5ca18c0164a441d6078f2379d728fceR22
04:30 Will_the_Chill oh well like I said, Inline::C is the reason why RPerl is possible, so sorry I can't help your hatred in that regard
04:33 Will_the_Chill bulk88: looks like I already knew about this issue, from the pastie.org: "'#include <unordered_map>',  # DEV NOTE: unordered_map may requi
04:33 Will_the_Chill re '-std=c++0x' in CCFLAGS above"
04:38 bulk88 but you can't do that on MSVC or Sun C++ http://docs.oracle.com/cd/E18659_01/html/821-2676/CCplusplus.1.html ;-)
04:38 Will_the_Chill okay I'm confused, if I look in lib/RPerl/HelperFunctions_cpp.pm then I see the needed line is already there  CCFLAGS => '-Wno-deprecated -std=c++0x',
04:38 Will_the_Chill but then in your pastie output all the other Inline args are present EXCEPT the CCFLAGS option!  how did it disappear???
04:38 Will_the_Chill did you comment it out in your code?
04:38 bulk88 let me check
04:39 bulk88 yes I removed it it because it broke the MSVC build attempts
04:41 bulk88 https://github.com/bulk88/rperl/commit/e31d2cc0d14a8e368e2530451ea4159740d3bde8 my source tree ATM
04:42 Will_the_Chill OH so it was your fault, haha!
04:50 bulk88 http://pastebin.com/nex9Nxc1 while reverting the ccflags removal, I realized, why is the same boiler plate to Inline being copy pasted into a dozen files? also why are you using a heredoc then string eval instead of a eval on a block? the heredoc is a very strange coding style
04:51 bulk88 you know a BEGIN {require Class then Class->import()} is a use?
04:53 Will_the_Chill refactoring comes later, functionality comes first
04:54 Will_the_Chill and yes I fully realize it will need refactoring
04:57 bulk88 FYI, Inline produces EU::MM mini modules/make makefiles
04:59 bulk88 http://pastie.org/private/w9auc7nnj0dqy9wto8z1a GCC 4.6.3 doesn't have to_string method, just like VC 2010 was erroring
05:01 Will_the_Chill bulk88: http://stackoverflow.com/questions/12975341/to-string-is-not-a-member-of-std-says-so-g
05:01 Will_the_Chill "This is a known bug under MinGW. Relevant Bugzilla. In the comments section you can get a patch to make it work with MinGW."
05:02 Will_the_Chill different answer: http://stackoverflow.com/questions/19122574/to-string-isnt-a-member-of-std
05:03 Will_the_Chill this second page implies you may need to use "-std=c++11" instead of "-std=c++0x"
05:06 Will_the_Chill I'm not sure which of those 2 pages gives the correct answer, hopefully 1 is right!  :)
05:07 bulk88 http://pastebin.com/nVXtkiSH the GCc in question
05:08 Will_the_Chill okay cool?
05:09 Will_the_Chill not sure what to get out of that one
05:11 bulk88 that spec file is another reason I refuse to use GCC, Mingw.org and Mingw64 and Cygwin have 3 different spec files, and occasionally each GCC family changes their spec file, the spec file controls default cmd line options you never see, so "gcc main.c" always makes main.o, even though there are 10-25 command line options being passed to the C compilers under the hood
05:12 bulk88 if you breath at that spec file, Win32::API (my CPAN module), crashes at runtime
05:13 Will_the_Chill okay
05:13 Will_the_Chill SLIGHT TANGENT: will you please up-vote my re-attempt at Slashdot?  THANKIES!  :)  http://slashdot.org/submission/3160633/perl-will-finally-have-a-compiler
05:16 bulk88 the problem with what you dug up at http://stackoverflow.com/questions/12975341/to-string-is-not-a-member-of-std-says-so-g http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 is, I have no clue if this is about Mingw.org or Mingw64 (what SP 5.16 uses)
05:19 Will_the_Chill my problem is I don't know anything about Minigw at all
05:19 Will_the_Chill :/
05:26 bulk88 http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3383  http://latimesblogs.latimes.com/alltherage/images/2007/09/19/cats_fighting_102006_5.jpg
05:28 Will_the_Chill so they don't have a well-organized development focus?
05:31 bulk88 Mingw.org decided to be conservative and "if I didn't write it, its not going in", and refused to add any support for making Windows 64 bit binaries, Mingw.org told people who wants to make 64 bit binaries to F-off because Win64 can run Win32 binaries flawlessly, and there is no legitimate reason for GCC to make Win64 binaries because "Win32 binaries are Win64 binaries"
05:31 bulk88 a bunch of ReactOS related devels then forked Mingw.org's code, created Mingw-64, and never looked back
05:32 bulk88 Mingw-64 binaries can create Win32 and Win64 binaries, old Strawberry Perls used Mingw.org, SP
05:33 bulk88 's author eventually switched to Mingw-64 (I dont remember the version of SP when it happened) because otherwise 64 bit strawberry perl wouldn't exist
05:39 bulk88 ok, the GCC bugzilla ticket is about Mingw64, which is the 4.6.3 that failed when I did an RPerl try with it
05:40 Will_the_Chill so the patch will fix it?
05:43 bulk88 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015#c25
05:43 * bulk88 thinks if someone downloads a compiler from mingw.org they have been successfully trolled
05:46 Will_the_Chill well, compilers are hard to build, what can I say.  :)
05:47 bulk88 latest strawberry, 5.18.1 from aug 2013, uses Mingw64 4.7.3, not >= 4.8.0, it won't fix this bug
05:49 bulk88 ill just give my 2 cents, nearly every last problem with RPerl I have delt with is because of it using way too new C++ features, people do not use the latest bleeding edge tools, if it doesn't support out of the box the last 5 years of toolchains/dependencies, a large amount of the potential user base wont use
05:50 Will_the_Chill This is why I have accepted the need to budget money for getting the Windows version working
05:50 bulk88 in 2013, people still use my Win32::API module on Perl 5.6, they weren't trolling
05:51 mirjam joined #perl11
05:51 Will_the_Chill I can't take out Inline or C++11 until somebody provides equivalent replacement code
05:51 Will_the_Chill and I doubt that's gonna happen
05:52 Will_the_Chill plus we shouldn't be running away from C++11, it is an international standard and 2 years old
05:52 Will_the_Chill it sucks that you are having issues, I'm not diminishing that at all
05:52 Will_the_Chill I'm just saying the issues must be overcome one way or another
05:52 bulk88 they complain when Win32::API blew up on 5.6, in 2013, its not my job to ask WTH they are using 5.6, but they are, so I backported Win32::API to 5.6. I would guess they used a Win32::API from > 5 years ago, and decided to upgrade, then realized support for 5.6 was dropped/not tested for years, then complained to get back 5.6 support
05:52 Will_the_Chill and if it works in Linux then by golly we can get it to work in Windows
05:53 bulk88 the solution is to use an older version of C++, it takes time (in years) for the 2 inch ISO standard binder to be implemented in software
05:57 Will_the_Chill the solution is to figure out how to get RPerl to compile properly in windows, because it works fine in linux
05:58 Will_the_Chill If Windows really is that incapable of compiling standardized C++, then it just reinforces my love for not-Windows.  ;)
05:58 Will_the_Chill Anyway, I'm convinced it is just some amount of config-mangling needed to get RPerl to compile in Windows.
05:59 * bulk88 buys a cryo cylinder and crawls in to be hibernated for 5 years
05:59 Will_the_Chill I can see from your compile attempts that you are getting very close to success!
05:59 Will_the_Chill LOL @ cryo cylinder  :D
06:01 bulk88 it would be easier to use change RPerl to use C++03 IMO, but I know nether C++ versions and dont want to know, so I'm not going to start backporting Rperl on the fly
06:02 bulk88 even GCC doesnt claim full C++11 compatibility  http://gcc.gnu.org/onlinedocs/gcc-4.8.2/libstdc++/manual/manual/status.html#status.iso.2011
06:02 Will_the_Chill C++11 is used for hashes only
06:03 Will_the_Chill my prediction: by the time we have enough RPerl traction to care enough to re-implement the C++11 bits into some older C++, it will be a moot point because C++11 implementations will have caught up.
06:04 Will_the_Chill but if the Windows guy I hire says it is IMPOSSIBLE to get C++11 to compile in Windows... well I'll prolly fire him and hire somebody else... but if MULTIPLE experts say C++11 won't work in Windows, I guess we can reconsider then.
06:04 Will_the_Chill as it is, I see you getting very close to success, as I've said.  getting Inline code to compile is not trivial.
06:05 Will_the_Chill but it is AWESOME when it finally works.  :)
06:10 bulk88 "it will be a moot point because C++11 implementations will have caught up." I wouldn't bet on it, the C/++ standards work like this, a dozen OS specific toolkits and generic frameworks (Boost/QT/Glib/ACE/Wx/NSPR) implement the same feature, after that feature being stbale for 2-5 years the the ISO committes agenda the feature, then after 5 more years, they release a standardized API of that
06:10 bulk88 feature in the latest ISO C/++
06:10 bulk88 so for the last 10 years, the feature in the "brand new" ISO C, has been implemented in 3rd party general purpose frameworks
06:11 Will_the_Chill well the question is whether we will have the resources to re-implement the C++11 parts, or if we will just wait for the C++11 implementations to catch up.
06:11 bulk88 since all production code used the feature from the quick and nimble 3rd party frameworks, they dont care for the ISO version of that feature
06:11 Will_the_Chill I'm not going to personally put any of my time into re-implementing code that works just fine.
06:12 Will_the_Chill BUT if it becomes a major show-stopping issue then we can get somebody to work on it.
06:20 bulk88 http://sourceforge.net/projects/perlmingw/ Strawberry Perl doesn't use Mingw64's binaries but compiles their own from Mingw64's source, so SP's upstream source GCC is at 4.6.3 right now
06:22 Will_the_Chill okay sorry sometimes I have a hard time grasping the point...  what does this mean?
06:22 Will_the_Chill AFK
06:25 rurban1 joined #perl11
07:06 bulk88 I tried Mingw64 4.8.3, ld.exe SEGVed
07:08 bulk88 why? I know why, because none of the GCCs are forwards or backwards compatible with any .o'es they make, nor do they encode version numbers of COFF/AR
07:12 bulk88 http://i40.tinypic.com/rvf4n7.png
07:13 Will_the_Chill okay
07:14 Will_the_Chill so why did ld.exe crash?
07:16 bulk88 simple answer=because Apple said it is a horrible product and made clang
07:16 bulk88 the exact answer I can't give, because of symbol problems and Im sure the binary is tripped
07:16 bulk88 *stripped
07:18 Will_the_Chill well I'm still confused about why all of this works just fine for me on a version of Linux from 2010 (and upgraded gcc)
07:18 Will_the_Chill I guess I'm just spoiled with an absolutely wonderful operating system
07:19 Will_the_Chill and inexpensive, too!
07:19 bulk88 Ive only once ever seen Visual C crash, when I gave it a > 65K "?:" chain statement
07:20 bulk88 usually Visual C errors out gracefully
07:21 bulk88 GCC doesnt error out, it produces SEGVing binaries or crashes
07:22 mirjam joined #perl11
07:22 bulk88 http://pastebin.com/qfKkKTB7 the actual command line passed to ld from the compiler driver
07:22 Will_the_Chill cool
07:26 bulk88 GCC is a compiler that was written so only GCC's own devels can use it, too much flexiblity, and that means that if you breath at it it breaks because of at a distance problems
07:26 bulk88 the idea backwards and forwards compatiblity doesn't exist on Linux, you use the C compiler your package manager downloads for you and you never question it
07:26 rurban1 joined #perl11
07:27 bulk88 and the distro devels can change whatever they want, so no ABI or compatibility, POSIX covers source compatibility, not toolchain/make/cc cmd flags
07:29 Will_the_Chill okay I think I mostly understand
07:30 Will_the_Chill it is harder to compile things in Windows because you have to be compatible with multiple different versions of Windows at all times?
07:30 bulk88 in that pastebin, what happened was, .a from a 4.6 GCC were used on a 4.8 GCC, due to EU:MM/Perl issues
07:31 bulk88 what happens is, if you pass custom libs with "-lfoo" to EU::MM in that hash, it absolute paths all the default -l libs in Config.pm
07:33 bulk88 http://pastebin.com/QWvUewmP the cmd line to compiler driver g++
07:35 bulk88 I dont get this BS with Visual C, I've used 2003 ".lib"s (VC's name for a .a) on VC 6, and VC 6 .libs on VC 2003 without a problem, VC 6 can't use VC 2008 .libs, but VC 2008 can use VC 6's .libs
07:39 Will_the_Chill okay
07:39 Will_the_Chill you know it might "just work" in cygwin
07:40 Will_the_Chill or VC 2012 for that matter
07:44 bulk88 will be trying my Cygwin when all the dep modules install, that will take 15 mins
07:44 bulk88 it will probably fail due to my Cygwin having 4.5.3
07:45 bulk88 my cygwin64 has 4.8.2 though
07:46 Will_the_Chill my gcc is 4.5.2
07:46 bulk88 Cygwin GCC is a seperate fork from Mingw.org and Mingw64, they are growing like Linux distros
07:47 bulk88 Cygwin GCC shares no code with .org or w64 except for whatever GNU org publishes
07:47 bulk88 so all the headers are different
07:47 Will_the_Chill yeah I was wondering if those things were connected
07:47 Will_the_Chill that sounds really weird
07:47 Will_the_Chill why did they do it that way?
07:48 bulk88 "we are POSIX platform, we will use POSIX as much as possible, posix paths everywhere in our headers"
07:48 bulk88 there is also "Msys", I'm not sure where they get their GCC from, or what their headers/SDK is
07:49 bulk88 so Perl on Windows, has 7 different platforms, Cygwin GCC, Mingw.org GCC, Mingw64 GCC, Msys, Visual C, Interix GCC, Interix Visual C
07:50 bulk88 http://msysgit.github.io/ home of "Msys" and "Msys Perl for Windows"
07:51 bulk88 Does OS/2 count as an 8th Perl on Windows platform :-p?
07:51 bulk88 because windows can run text mode OS/2 binaries
07:52 Will_the_Chill what about activeperl and strawberry perl and vanilla perl?  are they on the list?
07:54 bulk88 ActivePerl from day 1 until 2013 was "Visual C", it is now Mingw64 plaform
07:54 bulk88 Strawberry perl was Mingw.org on day1, it switched to Mingw64 platform some years ago
07:55 bulk88 I'm not sure what Vanilla Perl is
07:56 Will_the_Chill gotcha
07:56 bulk88 there is also Borland C, but it is throughly dead
07:56 Will_the_Chill yeah I remember Borland
07:57 Will_the_Chill THE GOOD OL' DAYS
07:57 Will_the_Chill okay maybe not _that_ good, haha!  ;)
07:59 bulk88 my opinion is, on Windows, Visual C defines the ABI and the OS, and you have to be compatible with Visual C and its DLLs, its debugging tools, and its object files
07:59 bulk88 imagine if Clang wasn't GCC compatible
07:59 Will_the_Chill okay
07:59 Will_the_Chill so you're saying since VC and Windows are both MS then VC is the official Windows compiler
08:00 Will_the_Chill and since gcc and Linux are both GNU, then gcc is the official Linux compiler
08:00 bulk88 yes
08:00 Will_the_Chill and clang by extension
08:00 bulk88 yes
08:00 Will_the_Chill gotcha
08:00 bulk88 clang was made for BSD AFAIK, not Linux
08:00 bulk88 I'm not sure what BSD used before GCC
08:00 Will_the_Chill well clang was made for LLVM
08:00 Will_the_Chill I thought
08:01 bulk88 AFAIK, LLVM is a library, not an executable binary, LLVM doesnt take in any plain text
08:02 Will_the_Chill rurban is the LLVM expert, not me
08:02 Will_the_Chill but yes I think you may be correct
08:02 bulk88 clang is a C parser/cmd line tool for LLVM library
08:02 Will_the_Chill right
08:03 Will_the_Chill my point is I wasn't aware that LLVM was somehow specially linked to BSD
08:03 Will_the_Chill I've always just known it to run in Linux as well as whatever other operating systems
08:05 bulk88 http://pastebin.com/hBPAi1dC nothing ever works right, installing Inline on Cygwin
08:10 Will_the_Chill yeah there are also issues installing Inline in Linux
08:11 Will_the_Chill those errors from your last pastebin look familiar, but I don't recognize any of the dll's cuz we don't have those in Linux
08:11 Will_the_Chill remember your favorite install docs???  http://rperl.org/use_rperl.html
08:12 Will_the_Chill you must first get the custom MyConfig.pm installed and loaded into cpan
08:12 Will_the_Chill then you must do "force install Inline"
08:12 Will_the_Chill read the use_rperl.html page
08:12 Will_the_Chill it's all written on there
08:13 Will_the_Chill I'm not saying it will fix your problems, but I'm also pretty sure it won't work without it
08:21 bulk88 http://pastebin.com/1MuDgBbJ
08:25 bulk88 switching to my branch, now need to install Inline:CPP
08:27 rurban1 joined #perl11
08:31 Will_the_Chill cool
08:33 Will_the_Chill I've recently updated the tests a bit, it would probably be good for you to download the latest tarball from github
08:39 bulk88 02_inline passes, 03 fails starting at  "not ok 37 - RPerl::DataType::Number_cpp::cpp_load();"
08:39 bulk88 http://pastebin.com/7k1smKYY
08:41 bulk88 will get fresh from your repo
08:46 Will_the_Chill I see the same warning that Reini was telling us about earlier today: "warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]"
08:47 Will_the_Chill I don't know what's causing that, and it doesn't appear on my build AFAIK
08:47 Will_the_Chill but the actual error seems to be our recent friend "error: ‘to_string’ is not a member of ‘std’"
08:52 mirjam joined #perl11
09:00 bulk88 http://pastebin.com/KyBUQzWW I'm not sure if your software stack is as stable as the cop or the bum in this video http://www.youtube.com/watch?v=DqHDgde9Nkw
09:04 Will_the_Chill remember you replaced "/tmp/RPerl-latest" with something like "../something/RPerl"
09:04 Will_the_Chill it was the original includes path issue you already fixed
09:04 bulk88 Inline::Filters failed to install
09:04 Will_the_Chill *fixed for yourself
09:05 Will_the_Chill back here again!   http://rperl.org/use_rperl.html
09:05 Will_the_Chill cpan> force install Inline::Filters
09:05 bulk88 http://www.cpantesters.org/distro/I/Inline-Filters.html
09:06 bulk88 I'm not patching my perl install, a cpan smoker won't patch its perl for you
09:07 bulk88 BTW, until http://www.cpantesters.org/distro/I/Inline-Filters.html passes, you will never get any CPAN reports
09:07 bulk88 if you convert RPerl to be a normal CPAN module
09:07 Will_the_Chill yes I know I have to get Ingy or somebody to let me patch Filters
09:07 Will_the_Chill I don't know what you mean when you say "patch my perl install"
09:08 Will_the_Chill I thought you already did some simple fix for this?
09:09 bulk88 I know what I did wrong
09:09 bulk88 nvm
09:09 bulk88 actually, I think I know how to clean up the Inline::Filters dep mess
09:10 bulk88 bump your filters version number to 0.13_01 (I dont remember if 0.12_01 > 0.12 or < in Perl version logic)
09:10 bulk88 then do a use and pass a vstring
09:13 bulk88 even if someone install 0.12 manually or with CPAN (which wont work, but anyway), the error message will be very clear that you require 0.13
09:13 Will_the_Chill oh I see
09:14 Will_the_Chill good idea!
09:14 Will_the_Chill I was just about to ask you, how do I see if somebody other than the (now non-Perl) Neil Watkiss has permission to update the Inline::Filters CPAN namespace?http://search.cpan.org/~neilw/Inline-Filters-0.12/
09:20 Will_the_Chill ingy: you are copied on an e-mail I just sent to Neil Watkiss about an error I fixed in Inline::Filters, necessary for RPerl to function
09:20 Will_the_Chill rurban: you too
09:20 Will_the_Chill bulk88: you too.  ;)
09:22 shadowpaste joined #perl11
09:23 shadowpaste "bulk88" at 217.168.150.38 pasted "@@ -89,21 +89,58 @@ sub Strip_" (89 lines) at http://paste.scsys.co.uk/282628
09:24 Will_the_Chill what's that about?
09:24 bulk88 Filters.pm, your changes vs the stuff in the RT ticket for Filters.pm
09:25 Will_the_Chill oh yeah I just saw that RT ticket a few mins ago
09:25 bulk88 the change in RT is adding "    no strict "refs";"
09:25 Will_the_Chill yes I see that
09:25 Will_the_Chill I think that is different than my change
09:25 Will_the_Chill unless they somehow have the same effect?
09:26 bulk88 your code is confusing, didnt you step the code see what $ilsm->{ILSM}{MAKEFILE}{INC} is?
09:27 bulk88 or is "INC" a sub that executes or soemthing?
09:27 bulk88 and why "UNIVERSAL::isa($ilsm->{ILSM}{MAKEFILE}{INC}, 'ARRAY')" instead of ref()?
09:27 Will_the_Chill I dunno I wrote that fix a while back
09:28 rurban1 joined #perl11
09:28 Will_the_Chill it was assuming INC was an array when I guess I needed it to optionally be a non-array
09:28 Will_the_Chill so I added that logic to correctly put the info into @inc_array
09:30 bulk88 I'm debating whether to do an unauth release on CPAN of inline Filters for you
09:31 Will_the_Chill well I just e-mailed Neil Watkiss
09:31 Will_the_Chill so maybe we should give him a day or three
09:31 Will_the_Chill we will need to do unauth if he doesn't reply
09:31 Will_the_Chill but I want to try to do auth
09:31 Will_the_Chill that's the best plan, right?
09:34 bulk88 I doubt that email will work by now, wanna see if this is him https://twitter.com/wheelnotkiss ?
09:34 Will_the_Chill the watkiss.ca domain is his wife's current blog
09:35 Will_the_Chill yeah that's him on twitter
09:35 Will_the_Chill I don't have a twitter account
09:35 bulk88 I saw that, I thought the domain expired and was taken over by unrelated person
09:35 Will_the_Chill can I somehow e-mail him at twitter?
09:35 bulk88 you have a FB?
09:35 Will_the_Chill I do have FB
09:37 bulk88 https://www.facebook.com/neil.watkiss probably him
09:38 Will_the_Chill yeah that's him
09:38 Will_the_Chill I'll message him on FB
09:40 Will_the_Chill done
09:40 Will_the_Chill so now he has an e-mail and a FB message
09:40 Will_the_Chill ingy and rurban are copied on both
09:40 bulk88 installing Inline::C on a Perl 5.12, it picked up 40 dependencies including EU::MM
09:41 Will_the_Chill Yeah Inline is kinda big I guess
09:41 Will_the_Chill oh, is your point that EU::MM is a good choice because Inline uses it already?
09:42 shadowpaste Someone at 217.168.150.38 pasted "Using included version of CPAN" (20 lines) at http://paste.scsys.co.uk/282631
09:44 Will_the_Chill I love watching CPAN modules install!  :D
09:45 bulk88 I hate it, the upgrades usually mean when I do back compat testing with CPAN modules I won't catch bugs in older EU::MMs, but I code the dep versions in META.yml as 0/any version
09:45 bulk88 03_inline_cpp.t passed on cygwin
09:46 Will_the_Chill nice!
09:46 Will_the_Chill that's pretty important, haha!  :)
09:47 shadowpaste "bulk88" at 217.168.150.38 pasted "Administrator@dl585 /cygdrive/" (50 lines) at http://paste.scsys.co.uk/282633
09:47 bulk88 04 failed tho
09:48 shadowpaste "bulk88" at 217.168.150.38 pasted "Administrator@dl585 /cygdrive/" (61 lines) at http://paste.scsys.co.uk/282634
09:49 Will_the_Chill "/tmp/RPerl-latest/" strikes again!
09:54 shadowpaste "bulk88" at 217.168.150.38 pasted "to_string is back on Cygwin GCC 4.8.2" (974 lines) at http://paste.scsys.co.uk/282638
09:54 shadowpaste "bulk88" at 217.168.150.38 pasted "gcc -v" (9 lines) at http://paste.scsys.co.uk/282639
09:56 Will_the_Chill dang
09:59 Will_the_Chill http://tehsausage.com/mingw-to-string
09:59 bulk88 I'm not on Mingw, I'm on Cygwin
10:00 Will_the_Chill oh dang
10:01 Will_the_Chill hmm  *scratches head*
10:02 bulk88 http://comments.gmane.org/gmane.os.cygwin/143270 they released something new in the last 24 hours? *sigh*
10:02 bulk88 but thats mingw64 package for Cygwin, not Cygwin GCC
10:02 Will_the_Chill WOW
10:02 Will_the_Chill THE BLOOD IS STILL FLOWING
10:03 Will_the_Chill (it is _that_ bleeding edge)
10:03 Will_the_Chill it is as if the universe just WANTED you to have it
10:03 Will_the_Chill :)
10:04 Will_the_Chill I just KNOW there's got to be a way to get it to wokr
10:04 Will_the_Chill *work duh
10:07 bulk88 hire a GCC devel
10:08 Will_the_Chill why do you say that?
10:13 bulk88 +<sarcasm></sarcasm>
10:13 Will_the_Chill oh I see!  :)
10:13 shadowpaste "bulk88" at 217.168.150.38 pasted "-std=c++0x ???????" (1 line) at http://paste.scsys.co.uk/282642
10:14 Will_the_Chill what's the problem?
10:14 Will_the_Chill -std=c++0x is good
10:14 Will_the_Chill remember it is supposed to be there?
10:14 Will_the_Chill it was the thing you had commented out in the CCFLAGS var before?
10:16 shadowpaste "bulk88" at 217.168.150.38 pasted "maybe this is to_string declaration" (111 lines) at http://paste.scsys.co.uk/282643
10:17 Will_the_Chill looks like it
10:17 Will_the_Chill checking that flag _GLIBCXX_HAVE_BROKEN_VSWPRINTF was part of the bug discussion
10:17 Will_the_Chill in some of the forums we were reading earlier
10:18 shadowpaste "bulk88" at 217.168.150.38 pasted "another to_string declaration" (109 lines) at http://paste.scsys.co.uk/282647
10:21 bulk88 I poisoned both header files (basic_string.h and vstring.h), neither were probably included
10:22 Will_the_Chill poisoned?
10:23 Will_the_Chill okay I don't know which of those to_string() declarations is the right one
10:24 Will_the_Chill I didn't have to dig that deep on my system
10:24 Will_the_Chill to_string just worked
10:28 rurban1 joined #perl11
10:28 Will_the_Chill rurban1: you awake?
10:31 bulk88 per http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 and C++11 section 21.4 and 21.5, you need -std=c++11
10:32 Will_the_Chill yeah I mentioned that as a possibility a few hours ago I think
10:32 Will_the_Chill I wasn't sure if "-std=c++0x" and "-std=c++11" were the same or not
10:33 Will_the_Chill if it works for you then I will test it on my end
10:33 bulk88 I dont know either if "-std=c++0x" and "-std=c++11" are the same or not, http://gcc.gnu.org/onlinedocs/libstdc++/manual/using.html#manual.intro.using.flags 0x seems to be purged
10:35 bulk88 http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/C-Dialect-Options.html#C-Dialect-Options they are equivelent
10:36 Will_the_Chill huh
10:40 bulk88 ‘c++11’ and ‘c++0x’ have the same section
10:40 Will_the_Chill cool
10:40 Will_the_Chill thanks for that info
10:40 Will_the_Chill that's good to know
10:41 bulk88 you should get familiar with GCC's man pages if you are going to use it
10:42 Will_the_Chill oh yeah I think I looked that up a long time ago
10:42 Will_the_Chill maybe  :)
10:43 Will_the_Chill well I had the flag in there, didn't I!  haha
10:43 Will_the_Chill so I'm sure I did look it up at some point
10:44 Will_the_Chill I probably just forgot about it
10:48 bulk88 "#if ((__cplusplus >= 201103L) && defined(_GLIBCXX_USE_C99) \
10:48 bulk88 && !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF))" is required to have to_string
10:49 bulk88 _GLIBCXX_USE_C99 is undef
10:49 Will_the_Chill oh dang
10:49 Will_the_Chill so do we need to define _GLIBCXX_USE_C99 ourselves?
10:49 Will_the_Chill I could put that in one of the header files
10:50 bulk88 http://stackoverflow.com/questions/17950814/how-to-use-stdstoul-and-stdstoull-in-android
10:50 bulk88 wanna file a dozen tickets? :-p
10:52 Will_the_Chill okay I just read that article
10:52 Will_the_Chill so this is a problem in stdlib?
10:52 Will_the_Chill in GNU libc I guess I should say?
10:52 Will_the_Chill gnu stdlibc++
10:53 Will_the_Chill okay that article is about an Android-specific example that is very close to our issue
10:54 Will_the_Chill clearly we don't need the Android-specific answer they reached of "try this other Android software"
10:54 Will_the_Chill but the smart answer did mention gnu stdlibc++
10:54 Will_the_Chill and the undef _GLIBCXX_USE_C99
10:54 Will_the_Chill so how come it works for me and not you?
10:56 bulk88 http://stackoverflow.com/questions/17950814/how-to-use-stdstoul-and-stdstoull-in-android that post makes no sense, "/* #undef _GLIBCXX_USE_C99 */" is quoted, that is the same on my machine, that is commented out
10:56 bulk88 so #undef _GLIBCXX_USE_C99 should (but where?) be defined on Android ARM in the SO post, and on my machine
10:57 Will_the_Chill oh well then I don't know
10:58 Will_the_Chill somehow I didn't have this issue
10:58 Will_the_Chill after I added the "-std=c++0x" flag
10:58 Will_the_Chill maybe not before either
10:58 bulk88 http://stackoverflow.com/questions/14381137/eclipse-function-to-string-could-not-be-resolved
11:01 Will_the_Chill so we have to define GXX_EXPERIMENTAL_CXX0X
11:02 Will_the_Chill and also __cplusplus to something over 201103L
11:02 Will_the_Chill ?
11:02 bulk88 https://www.mail-archive.com/freebsd-toolchain@freebsd.org/msg00751.html
11:04 bulk88 it seems to be a configure script problem
11:05 Will_the_Chill okay you lost me on that last BSD post
11:05 bulk88 http://cygwin.com/ml/cygwin/2007-05/msg00486.html Cygwin calls it a "
11:05 bulk88 wont fix" in 2007
11:07 Will_the_Chill okay
11:07 Will_the_Chill those last 2 articles were about C99
11:07 Will_the_Chill does that apply to us?
11:07 bulk88 windows has a dozen OSes to support, POSIX has 1000s of OSes to support, hence Configure, because POSIX isn't really a standard you can build software on
11:08 Will_the_Chill okay and what does that mean for us?
11:09 bulk88 I think, the libstdc build process (through Configure) on Cygwin decided to not allow math conversion parts of C++11 to exist because the platform doesn't support C99 math (now lets talk about spec files and GCC builds!)
11:09 Will_the_Chill so can't we just short-circuit that disallowing by re-allowing it in our own header files?
11:10 bulk88 "#define _GLIBCXX_USE_C99" and see what happens?
11:12 bulk88 obviously GCC 4.8.2 on Cygwin supports C99 math, but something somewhere went wrong in the interaction of the Cygwin GCC and the libstdc build process, self bootstraping issues probably (chicken egg????)
11:14 bulk88 I'm not going to bother filing bugs over this mess, as in the 2007 post, Cygwin, unless the reporter supplies a patch, will reject the bug and say goto libstdc, libstdc will reject the ticket and tell you to goto Cygwin and tell them to implement whatever Configure didn't find
11:15 bulk88 then comes the issue, of how on earth do you build a GCC, obviously not with Visual C
11:16 bulk88 now we get into how Cygwin does automated builds of their psuedo-OS
11:16 Will_the_Chill yes I follow you
11:16 Will_the_Chill but again, can't we just try to add the define to our own header files?
11:17 bulk88 where do I add it? my head is drained
11:17 Will_the_Chill hang on
11:18 Will_the_Chill I would try lib/RPerl/HelperFunctions.h
11:19 bulk88 it has to be before ALL includes
11:19 bulk88 where is #include <string>?
11:19 Will_the_Chill that is in the Inline config eval string
11:19 Will_the_Chill hang on
11:20 Will_the_Chill lib/RPerl/DataType/String_cpp.pm
11:20 Will_the_Chill inside AUTO_INCLUDE
11:21 Will_the_Chill my note there in the code:    # DEV NOTE: include non-RPerl files using AUTO_INCLUDE so they are not parsed by the 'Preprocess' filter
11:25 shadowpaste "bulk88" at 217.168.150.38 pasted "defined too late" (35 lines) at http://paste.scsys.co.uk/282657
11:26 shadowpaste "bulk88" at 217.168.150.38 pasted "poisoned header failed, search for #error _GLIBCXX_USE_C99" (215 lines) at http://paste.scsys.co.uk/282658
11:27 Will_the_Chill whoah
11:27 Will_the_Chill so AUTO_INCLUDE doesn't support #define I guess?
11:28 Will_the_Chill just try putting it in HelperFunctions.h and see what that does
11:29 rurban1 joined #perl11
11:30 bulk88 way too late, you know how C headers work?
11:31 Will_the_Chill yes I know how they work
11:31 Will_the_Chill try String.h
11:31 Will_the_Chill or types.h
11:31 Will_the_Chill I had to carefully design the stupid header files
11:31 Will_the_Chill because of how all the wacky auto-including works
11:31 Will_the_Chill I just don't remember the load order off the top of my head
11:32 Will_the_Chill *include order
11:32 Will_the_Chill I guess I should say
11:32 bulk88 basically, extern "C" {
11:32 bulk88 #include "EXTERN.h"
11:32 bulk88 #include "perl.h"
11:32 bulk88 #include "XSUB.h"
11:32 bulk88 #include "INLINE.h"
11:32 bulk88 after those, reinclude guards will stop 90% of the headers from reloading
11:33 Will_the_Chill to clarify, I mean to try putting the needed #define in lib/RPerl/DataType/String.h
11:33 Will_the_Chill or in lib/types.h
11:33 bulk88 too late see http://paste.scsys.co.uk/282657
11:34 Will_the_Chill both of those 2 are too late?
11:34 shadowpaste "bulk88" at 217.168.150.38 pasted "start of .c file" (65 lines) at http://paste.scsys.co.uk/282659
11:35 Will_the_Chill where should #define _GLIBCXX_USE_C99 be in the include order?
11:36 bulk88 before #include EXTERN.h initially
11:36 bulk88 depending on more conflicts, and figuring out exactly where string is first #included, the define may need to move
11:36 Will_the_Chill okay I'm looking into it
11:38 Will_the_Chill I think it may be the BOOT option for Inline
11:38 Will_the_Chill instead of the AUTO_INCLUDE option for Inline
11:38 bulk88 "Inline::Filters CPAN Maintenance‏" <- that email needs to goto http://lists.perl.org/list/module-authors.html most importantly
11:39 bulk88 read http://pause.perl.org/pause/query?ACTION=pause_04about#takeover
11:40 Will_the_Chill I thought we were gonna wait a day or 3 to let Neil Watkiss respond?
11:41 bulk88 http://lists.perl.org/list/modules.html actually is the correct one not module-authors, module-authors is a little more "wet"/social in discussion
11:41 bulk88 it doesn't matter, they want public record anyway of your emails
11:41 bulk88 if Neil doesn't remember his password anymore, you will be doing a takeover
11:42 Will_the_Chill roger that
11:42 Will_the_Chill so in lib/RPerl/DataType/String_cpp.pm
11:42 Will_the_Chill in the Inline eval string
11:42 Will_the_Chill somewhere in the options area where AUTO_INCLUDE and CCFLAGS are
11:42 bulk88 sometimes the module owner will respond, "you can be owner, I dont remember my password, gods/mods do something"
11:42 Will_the_Chill add this:
11:42 Will_the_Chill BOOT => "#define _GLIBCXX_USE_C99",
11:42 bulk88 1 min
11:44 Will_the_Chill it may also need to go into lib/RPerl/DataType/Number_cpp.pm
11:44 Will_the_Chill and lib/RPerl/HelperFunctions_cpp.pm
11:44 Will_the_Chill and eventually all the other *_cpp.pm files that have that boilerplate Inline eval string
11:45 Will_the_Chill I think Number_cpp.pm may get called before String_cpp.pm
11:45 Will_the_Chill and HelperFunctions_cpp.pm may be called before both of them, I can't remember
11:46 Will_the_Chill so if it doesn't work adding the new BOOT option to just String_cpp.pm, then add it to the other 2 as well
11:46 Will_the_Chill and I'm not sure on the syntax if it is   BOOT => "#define _GLIBCXX_USE_C99",
11:46 Will_the_Chill or     BOOT => ["#define _GLIBCXX_USE_C99"],
11:46 bulk88 https://skydrive.live.com/redir?resid=DCA201F1227DA3C2!334&amp;authkey=!ALMf2TGqhf4XYyo&amp;ithint=file%2c.cpp that is a preproc file from cygwin, save it, grep it, study it, I'll delete it soon
11:49 bulk88 #define __INLINE_CPP 1
11:49 bulk88 #ifndef bool
11:49 bulk88 #include <iostream><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
11:49 bulk88 #endif
11:49 Will_the_Chill I'm looking at it, it looks like a compiled version of the scalar test file
11:49 Will_the_Chill what about iostream?
11:50 bulk88 that line eventually loads <string>, which loads the proprietary basic_string.h, which tests for _GLIBCXX_USE_C99, and if defed, defines to_string
11:50 Will_the_Chill so you're saying we need #define _GLIBCXX_USE_C99 before #include <iostream>?
11:51 bulk88 yes
11:52 Will_the_Chill all those #include <iostream> are from AUTO_INCLUDE in the Inline eval string boilerplate of *_cpp.pm
11:52 Will_the_Chill did you try adding the BOOT option?
11:52 bulk88 OT: what is amazing in that .i file is, there isn't 1 mention of "win32" lol
11:52 Will_the_Chill the BOOT option may need to be added to all those *_cpp.pm files for all I know
11:59 shadowpaste "bulk88" at 217.168.150.38 pasted "the def went into the END of the .c" (43 lines) at http://paste.scsys.co.uk/282660
12:00 Will_the_Chill oh dang
12:00 Will_the_Chill okay then we need to use AUTO_INCLUDE
12:00 Will_the_Chill and create a 1-line file that just has the #define _GLIBCXX_USE_C99
12:01 Will_the_Chill and make it the first header file loaded by AUTO_INCLUDE
12:01 Will_the_Chill that should work
12:01 bulk88 that wont work
12:01 Will_the_Chill why?
12:01 Will_the_Chill iostream is loaded by AUTO_INCLUDE
12:01 Will_the_Chill and we just need to be before iostream, right?
12:02 shadowpaste "bulk88" at 217.168.150.38 pasted "AUTO_INCLUDE starts here" (41 lines) at http://paste.scsys.co.uk/282662
12:03 Will_the_Chill oh dang so somebody is including iostream other than me in AUTO_INCLUDE
12:03 Will_the_Chill and by somebody, I assume it is Inline?
12:04 bulk88 see why I like xsubpp/EU::MM toolchain, because *I* control the first line of the .c file
12:04 bulk88 and *I* write #include "perl.h"
12:05 Will_the_Chill pfft
12:05 Will_the_Chill it is Inline/CPP.pm
12:05 Will_the_Chill aka Inline::CPP
12:06 Will_the_Chill line 95
12:06 Will_the_Chill inject the #define there
12:06 Will_the_Chill THAT will work
12:07 Will_the_Chill that's where it all comes from
12:09 bulk88 there is a var before called $flavor_defs
12:09 bulk88 and that gets placed before the boilerplate
12:10 bulk88 im reading https://metacpan.org/pod/Inline::CPP#iostream-Standard-Headers-Namespaces-and-Portability-Solutions because falvor_defs is part of that
12:12 Will_the_Chill okay
12:15 Will_the_Chill I'm not directly utilizing the __INLINE_CPP_* anywhere in RPerl right now
12:16 shadowpaste "bulk88" at 217.168.150.38 pasted "Inline::CPP's (not Inline's AUTO_INCLUDE, which is a totally different setting) AUTO_INCLUDE is no good" (67 lines) at http://paste.scsys.co.uk/282665
12:19 shadowpaste "bulk88" at 217.168.150.38 pasted "from Inline::CPP::Config" (11 lines) at http://paste.scsys.co.uk/282666
12:19 Will_the_Chill okay
12:19 bulk88 <sarcasm>I think you should do a kickstarter for Inline first</sarcasm>
12:19 Will_the_Chill LOLcry
12:20 Will_the_Chill okay so do you put the #define in the flavors var or at line 95 in CPP.pm?
12:20 Will_the_Chill one of those 2 places should definitely work
12:20 bulk88 you are forgetting the other way of doing it
12:20 bulk88 -D
12:20 Will_the_Chill ?
12:21 Will_the_Chill is "-D" an option I don't know about?
12:22 bulk88 "g++ -c  -I"/cygdrive/c/sources/rperl/t" -I/tmp/RPerl-latest/lib -Wno-deprecated -std=c++0x -DUSEIMPORTLIB -O3   -DVERSION=\"0.00\" -DXS_VERSION=\"0.00\"  "-I/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE"   eval_566_dc87.c" you have to know what -D is
12:23 bulk88 there is also a -U
12:23 Will_the_Chill okay cool I guess
12:23 Will_the_Chill but if it is a bug that can be fixed in Inline::CPP, then shouldn't it be fixed in Inline::CPP?
12:24 bulk88 http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Preprocessor-Options.html#Preprocessor-Options
12:24 bulk88 Inline:CPP does not expose any way (unless Inline offers something, I'm not stepping this so IDK) to hook line 1 of the .xs file
12:26 Will_the_Chill okay but again, can't we just put the #define _GLIBCXX_USE_C99 on line 95 of Inline/CPP.pm?
12:27 bulk88 no wait, the 2 AUTO_INCLUDE's are the same
12:28 bulk88 i can as a hack, but, it will never run on anyone's machine but mine, so why bother, I'm looking up how to control CCFLAGS
12:30 Will_the_Chill okay that makes sense
12:30 rurban1 joined #perl11
12:30 shadowpaste "bulk88" at 217.168.150.38 pasted "of course it failed, still reading results" (300 lines) at http://paste.scsys.co.uk/282667
12:31 bulk88 my fault
12:32 Will_the_Chill right
12:34 shadowpaste "bulk88" at 217.168.150.38 pasted "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/cwchar:248:11: error: ‘::wcstold’ has not been declared using ::wcstold;" (300 lines) at http://paste.scsys.co.uk/282668
12:34 Will_the_Chill yeah I see that
12:34 Will_the_Chill huh
12:34 Will_the_Chill never heard of wcstold before
12:36 bulk88 brb
12:36 Will_the_Chill roger
12:36 bulk88 joined #perl11
12:38 bulk88 4what part of the "_" in _GLIBCXX_USE_C99 do you not understand? play with fire and you will be burned!!!
12:38 Will_the_Chill okay so you forgot an underscore?
12:38 bulk88 now I have to chase down the next error
12:38 bulk88 an identifier with _ means it is internal/private
12:38 Will_the_Chill it is exciting, like a treasure hunt or a mystery!  :D
12:39 bulk88 so since we are playing with the internals of the Cygwin headers, we are having problems
12:39 bulk88 I dont know enough C++ to file a bug ticket with Cygwin over this
12:40 Will_the_Chill and I don't know anything about Cygwin, haha!
12:41 Will_the_Chill so this is all due to to_string() needing the special bleeding-edge cygwin
12:42 Will_the_Chill and then somehow that bleeding-edge cygwin didn't have the correct #define _GLIBCXX_USE_C99?
12:42 Will_the_Chill and we can't do the #define _GLIBCXX_USE_C99 ourselves because it is interwoven with other unknown parts of cygwin?
12:43 bulk88 I have no idea what Cygwin did, the dec 2 release was for Mingw64 on Cygwin that will make Win32 Native binaries, not Cygwin GCC that makes Unix on Win32 binaries
12:43 Will_the_Chill oh so we never tried the new bleeding edge mingw64?
12:44 bulk88 no
12:44 Will_the_Chill okay I was confused about that part, sorry
12:44 bulk88 I'm trying Cygwin GCC 4.8.2"
12:44 bulk88 -"
12:45 Will_the_Chill is that the dec 2 release in question, or something different?
12:48 basiliscos joined #perl11
12:57 basiliscos joined #perl11
12:57 bulk88 that is not the dec 2 release
12:58 bulk88 when I tried to use a 4.8.* series Mingw64 earlier today, crashed ld.exe on me and I gave up and switched to a "proper OS" (AKA Cygwin)
12:59 basiliscos joined #perl11
12:59 bulk88 https://rt.perl.org/Ticket/Display.html?id=120670 ticket filed over P5 core format warnings from GCC C++11
13:00 Will_the_Chill looking
13:00 Will_the_Chill awesome!
13:01 Will_the_Chill yeah like I said Reini was complaining about that
13:01 Will_the_Chill I don't think I've seen it on my system?
13:01 Will_the_Chill I'm using old Perl v5.10.1
13:03 bulk88 I have no clue, depends on your GCC, you said you were using 4.5 series
13:03 bulk88 5.14 and 5.19 have the same format strings
13:03 bulk88 so 5.10 will probably have them
13:04 Will_the_Chill right
13:04 Will_the_Chill gotcha
13:09 shadowpaste "bulk88" at 217.168.150.38 pasted ""string"" (55 lines) at http://paste.scsys.co.uk/282677
13:09 bulk88 can you grep your C headers and tell me if "_GLIBCXX_USE_C99" is used anywhere in linux and whether there is bits\basic_string.h or basic_string.h file on your machine,  (on my machine its "C:\cyg64\lib\gcc\x86_64-pc-cygwin\4.8.2\include\c++\bits\basic_string.h" ), also what does "string" look like on yoru machine?
13:10 Will_the_Chill hang on
13:15 Will_the_Chill looking
13:15 Will_the_Chill I have files    /usr/include/c++/4.5/bits/basic_string.h      and  /usr/include/c++/4.4/bits/basic_string.h
13:16 bulk88 I think the path tells you which one you are using :-)
13:16 Will_the_Chill part of the Ubuntu package libstdc++6-4.5-dev
13:16 Will_the_Chill yeah I figured out the version number all by myself!  :)
13:17 Will_the_Chill _GLIBCXX_USE_C99 appears in tons of locations in the same path tree
13:18 bulk88 I have libstdc++6,  version 4.8.2-1
13:20 Will_the_Chill mine Version: 4.5.2-8ubuntu4
13:20 Will_the_Chill I don't understand your question, "what does string look like on your machine"?
13:21 Will_the_Chill OH it is a file with no dot or suffix in the name
13:21 Will_the_Chill I found it, hang on
13:23 Will_the_Chill http://pastebin.com/GNNS4wyg
13:23 Will_the_Chill okay I think I'm gonna hit the sack.  :-)
13:23 Will_the_Chill lots of fun tonight!
13:27 bulk88 not sure if you are here, where is _GLIBCXX_USE_C99 defined in your headers?
13:27 Will_the_Chill okay hang on
13:27 Will_the_Chill you mean what files contain it?
13:28 bulk88 "#define _GLIBCXX_USE_C99" Im not sure how much whitespace there will be
13:28 Will_the_Chill okay
13:29 Will_the_Chill /usr/include/c++/4.5/i486-linux-gnu/bits/c++config.h:1108:#define _GLIBCXX_USE_C99 1
13:30 Will_the_Chill and also
13:30 Will_the_Chill /usr/include/c++/4.5/i686-linux-gnu/bits/c++config.h:1108:#define _GLIBCXX_USE_C99 1
13:31 rurban1 joined #perl11
13:33 bulk88 can you paste/send all of your c++config.h file?
13:34 Will_the_Chill okay hang on
13:35 Will_the_Chill http://pastebin.com/KtzgGUjs
13:38 bulk88 http://pastebin.com/cg0sTrr1
14:31 rurban1 joined #perl11
14:43 bluescreen joined #perl11
15:01 mirjam joined #perl11
15:09 mirjam joined #perl11
15:15 rurban1 joined #perl11
17:29 rurban1 joined #perl11
18:05 dalek joined #perl11
18:16 mirjam joined #perl11
20:06 bluescreen_ joined #perl11
20:19 basiliscos joined #perl11
20:39 rurban1 joined #perl11
23:02 Will_the_Chill joined #perl11
23:52 rurban1 joined #perl11
23:57 mirjam joined #perl11

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