01:38:55  * auroraeosrosequit (Quit: Leaving.)
04:20:15  * bbelderquit (Ping timeout: 276 seconds)
06:44:31  * ender`joined
08:15:41  * [[zz]]quit (Ping timeout: 246 seconds)
08:15:53  * madewokherdquit (Remote host closed the connection)
08:28:48  * [[zz]]joined
13:39:26  * auroraeosrosejoined
13:52:28  * berdariojoined
13:53:08  <berdario>Hello, I'm trying to follow the instructions here: https://github.com/coapp/coapp.org/wiki/Setting-Up-Your-CoApp-Development-Environment
13:53:21  <berdario>but the windows sdk repeatedly fails to install
13:53:42  <berdario>here're the last lines of the log (it's too long to paste as a whole)
13:53:50  <berdario>http://dpaste.com/798174/
13:54:31  <berdario>it says ManualResetEvent CancelEvent, but obviously I haven't canceled it manually
13:55:00  <berdario>I already have mingw installed... is the windows sdk really needed? someone else already got the same error as me?
14:03:41  <berdario>I tried this fix: doesn't work... I'll reboot and try again
14:03:42  <berdario>http://ctrlf5.net/?p=184
14:03:59  * berdarioquit (Read error: Connection reset by peer)
14:05:52  * berdariojoined
14:40:34  * gixquit (Ping timeout: 240 seconds)
14:45:35  * gixjoined
14:59:43  * madewokherdjoined
15:21:11  * piscisaureus_joined
16:11:57  <berdario>FearTheCowboy: I'm currently cloning the cpython repo... it seems it' quite outdated (10 months old), and I'll try to build that as a first step
16:12:46  <berdario>I still don't have the Windows SDK installed, I hope that's not a problem (it may very well be, I actually never built cpython on windows, but afaik, it uses the visual studio compiler... even though I might be able to get it working only with mingw)
16:13:26  <berdario>do you have any suggestions, before I waste my time in attempting to do something unfeasible?
16:18:19  <auroraeosrose>berdario: you'll need the sdk ;)
16:18:44  <berdario>auroraeosrose: any suggestions on getting the SDK installed?
16:18:59  <auroraeosrose>it's really easy - what version of visual studio/express do you have installed?
16:19:03  <berdario>I don't have any visual studio installed at all... that might be required for the installation?
16:19:11  <auroraeosrose>no, actually it isn't
16:19:30  <auroraeosrose>what are you planning to build with if you don't have visual studio installed though ;)
16:19:33  <auroraeosrose>mingw?
16:19:39  <berdario>I have mingw
16:19:43  <auroraeosrose>if so that ships with their "own" sdk
16:20:12  <berdario>ok, so it might work... but the .buildinfo file might be different from a VS .buildinfo?
16:20:18  <auroraeosrose>but then remember c runtime libs should match ... so any libs should be different
16:20:29  <auroraeosrose>shouldn't be.... it's just a different compiler flavor
16:20:39  <auroraeosrose>but afaik we don't have any libs compiled with mingw for anything yet
16:21:00  <berdario>uh, so I'm on my own if I want to try to get things running with mingw
16:21:01  <auroraeosrose>and frankly a 2010/2012 visual studio build would be more useful
16:21:06  <berdario>ok
16:21:22  <auroraeosrose>LOL - you can add information to buildinfo files in the libraries you need to build multiple versions
16:21:52  <auroraeosrose>that's part of what coapp is for in developer world... but for actual users they probably are going to want stuff built with the latest microsoft compiler - all that stuff is free btw
16:22:13  <berdario>auroraeosrose: you said that actually, VS isn't required for the installation of the SDK... so, I shouldn't expect anything different from what I've got?
16:22:44  <auroraeosrose>well, I don't think mingw can use the microsoft sdk.... not sure, never tried it ;)
16:23:05  <berdario>uhm, auroraeosrose we're misunderstading each other
16:23:13  <auroraeosrose>perhaps
16:23:20  <berdario>I'll try to rephrase:
16:23:40  <berdario>I give up with mingw, since it's not so useful and I'm on my own to get things working
16:23:47  <auroraeosrose>ok
16:23:52  <berdario>I'll install Visual Studio, IF
16:24:04  <auroraeosrose>so you need 1. visual studio or visual studio express to get the compilers (you don't HAVE to use the IDE)
16:24:06  <berdario>there's any hope of getting the Windows SDK installed, after installing VS
16:24:17  <auroraeosrose>2. a newer windows sdk
16:24:26  <auroraeosrose>for libraries and headers
16:24:33  <auroraeosrose>an sdk ships with visual studio
16:24:38  <auroraeosrose>but you'll want a newer version
16:24:46  <auroraeosrose>and yes you can install the sdk before or after visual studio
16:25:06  <berdario>you said that VS (the compiler,at least) isn't required for the installation of the SDK... what I'm asking if that's really true
16:25:16  <berdario>ok, that's a problem
16:25:23  <auroraeosrose>what is a problem?
16:25:43  <auroraeosrose>you can install the sdk without visual studio installed - not very useful - but you can ;)
16:26:01  <auroraeosrose>it's just a bunch of library files, include files, and some binaries
16:26:05  <berdario>the fact that the sdk is supposed to install successfully even without the VS compiler: I tried that, and it fails
16:26:14  <auroraeosrose>how does it fail
16:26:29  <berdario>I already sent a mail to wsdkfdb@microsoft.com, but I don't hope to get an answer soon
16:26:58  <berdario>I assume you weren't here some hours ago... I'll copypaste the previous lines:
16:27:05  <berdario><berdario> Hello, I'm trying to follow the instructions here: https://github.com/coapp/coapp.org/wiki/Setting-Up-Your-CoApp-Development-Environment
16:27:06  <berdario><berdario> but the windows sdk repeatedly fails to install
16:27:06  <berdario><berdario> here're the last lines of the log (it's too long to paste as a whole)
16:27:06  <berdario><berdario> http://dpaste.com/798174/
16:27:06  <berdario><berdario> it says ManualResetEvent CancelEvent, but obviously I haven't canceled it manually
16:27:07  <berdario><berdario> I already have mingw installed... is the windows sdk really needed? someone else already got the same error as me?
16:27:11  <berdario><berdario> I tried this fix: doesn't work... I'll reboot and try again
16:27:13  <berdario><berdario> http://ctrlf5.net/?p=184
16:27:30  <berdario>I looked also at this in the meanwhile:
16:27:31  <berdario>http://msdn.microsoft.com/en-us/library/ee248512(v=vs.100).aspx
16:27:36  <berdario>I downloaded the sdk ISO
16:27:42  <berdario>but the end result is the same
16:28:08  <auroraeosrose>never had an issue - weird
16:29:00  <berdario>auroraeosrose: do you think it might be worth to try again, after installing VS?
16:29:11  <auroraeosrose>you can try - also I'd check your .NET installed version
16:29:23  <auroraeosrose>I have had issues with that
16:30:13  <berdario>I just updated to the last one with Windows Update this morning
16:30:27  <berdario>and I had to install the full profile (otherwise, the SDK doesn't even starts to install)
16:30:39  <berdario>any suggestions on how to check the .NET version?
16:32:02  <auroraeosrose>hmmm - no clue
16:40:45  <berdario>Uhm, weird... I have what was an msdnaa account
16:41:17  <berdario>I was about to download there a VS2012... but the 64 bit version, is only the "express" or the "team foundation server"
16:41:26  <berdario>the VS2012 professional, is only 32 bit
16:41:34  * berdariopart ("Leaving")
16:41:40  * berdariojoined
16:41:59  * berdarioquit (Read error: Connection reset by peer)
16:42:24  * berdariojoined
16:42:31  <berdario>my IRC client crashed -_-
16:42:59  <berdario>auroraeosrose: I actually never heard of the "team foundation server" version, what do you suggesto to fetch?
16:44:56  <berdario>uhm, on second thought, Microsoft Visual Studio Team Foundation Server, might actually be something completely different from what I'm looking for
16:46:18  <berdario>ok, it's the new Visual SourceSafe... ugh, better to stay away from that thing
16:46:35  <berdario>(kudos to microsoft for confusing people by changing, yet another time, their naming scheme)
16:48:22  <auroraeosrose>berdario: visual studio is only 32 bit
16:48:32  <auroraeosrose>;)
16:48:44  <berdario>O_o
16:48:45  <auroraeosrose>vs2012 profession is no doubt what you want
16:48:48  <auroraeosrose>or vs2010
16:48:56  <auroraeosrose>the 64 bit compiler is included in it
16:49:09  <auroraeosrose>it's just only available in a 32 bit version - don't ask (silly microsoft)
16:49:16  <berdario>oh, ok
16:49:32  <berdario>this is confusing btw: I can download
16:49:32  <berdario>Microsoft Visual Studio Express 2012 for Windows 8 Web Installer 32/64-bit (Italian) - DreamSpark
16:49:34  <auroraeosrose>the "32 bit" is what it's actually compiled for iteself
16:49:48  <auroraeosrose>do you have windows 8?
16:49:57  <berdario>or
16:49:58  <berdario>Microsoft Visual Studio Premium 2012 32-bit - Web Installer (Italian) - DreamSpark
16:50:01  <berdario>no, Windows 7
16:50:08  <auroraeosrose>then you want the second one
16:50:25  <auroraeosrose>the "for windows 8" probably just uses the "new" "windows store" format
16:50:27  * auroraeosroserolls eyes
16:50:33  <berdario>(but I think that I'll install Windows 8 soon... since it seems that now the final version is available)
16:50:41  <auroraeosrose>eh.... it's great on a touchscreen
16:50:44  <auroraeosrose>I hate it for desktop
16:50:50  * auroraeosroseis waiting for windows 9
16:50:58  <auroraeosrose>microsoft just seems to screw up every other version
16:51:19  <berdario>yes, it might actually prompt my parents to finally switch to linux: "see? this is the new windows ...enjoy it!"
16:51:26  <auroraeosrose>LOL
16:51:27  <auroraeosrose>doubt that
16:51:39  <auroraeosrose>maybe switch to a mac....
16:51:50  <auroraeosrose>but most people like to buy something other people can support for them ;)
16:52:18  <berdario>I have linux on a macbook, totally removed MacosX... I was never using it, and it was wasting precious space on my ssd :P
16:52:27  <berdario>but I digress
16:53:02  * ender|'s been trying Start8 since yesterday, but it's much buggier than Classic Shell, even if it's Start Menu implementation is closer to Windows 7's in some aspects
16:53:09  <ender|>(especially search is better)
16:54:48  <ender|>there's only two things that bother me in 8: Start Screen and Alt+Tab not working on my mouse
16:54:49  <berdario>btw, I totally missed that "for Windows 8", but I guess it just includes the bits to be able to develop WinRT applications
16:55:57  <ender|>the only thing i have to say about WinRT on desktop is http://eternallybored.org/tdwtf/metro4.png
16:57:56  <auroraeosrose>ick
16:57:57  <auroraeosrose>;)
16:58:10  <auroraeosrose>well I suppose I should get dressed today
16:58:13  <auroraeosrose>laaaazy weekend
16:58:47  <berdario>it seems like in 201x, everybody want to waste screen space
16:59:05  <berdario>Gnome shell, google
16:59:19  <berdario>google+, windows8... and probably other examples
16:59:35  <auroraeosrose>hehe
16:59:44  <berdario>btw I'm downloading VS... but it's a 1 GB download :(
16:59:50  <auroraeosrose>it's cause they want to be able to "write once and run on any form factor" - tablet, phone, etc.
17:00:00  <auroraeosrose>berdario: yeah, it's got a full sdk with it
17:00:06  <auroraeosrose>the sdk's are quite large ;)
17:00:11  <ender|>auroraeosrose: it just wastes soo much space
17:00:23  <berdario>eh, the Windows8 iso is just 3 GB
17:00:29  <auroraeosrose>agreed ender - I'm not a fan
17:00:33  <berdario>I mean: the SDK is 1/3 the size of the whole OS
17:00:34  <berdario>yes
17:00:42  <auroraeosrose>berdario: it's got a crapload in it ;)
17:00:48  <berdario>on Linux, the tools are so much smaller
17:00:57  <berdario>but, otoh... the Intel SDK is even bigger
17:01:10  <berdario>never had to install it luckily :D
17:01:23  <auroraeosrose>hehe
17:01:32  <auroraeosrose>yeah but they pack all the mfc and everything in there
17:01:38  <auroraeosrose>it's giant and half the stuff you never use
17:01:47  * auroraeosrosewishes they had a mini "gimme only C files" sdk
17:01:55  * ender|should finish migrating his domain to win2012
17:08:40  <berdario>I have a paltry 2Mbps line :/
17:09:22  <berdario>my idea of trying to quickly do a shallow fork of some project has gone to die alone in a gloomy dark corner
17:09:41  <berdario>(1h 37m remaining)
17:09:50  <berdario>I'll have to find something else to do now...
17:10:11  <berdario>btw... maybe you can tell me a little bit of information on what is the current status of coapp?
17:10:48  <berdario>if perl, lua and python are already available... then it should be able to also use coapp to package software that's not written in C, right?
17:11:40  <auroraeosrose>really should wait until FearTheCowboy is around to get an accurate picture
17:11:50  <auroraeosrose>afaik lua is the only one building and packaging reliably
17:12:09  <auroraeosrose>http://coapp.org/pages/packages.html - these are the packages that actually work
17:12:15  <madewokherd>we need more work before we can properly package extensions for those languages
17:12:16  <auroraeosrose>and perl is currently a monolithic build
17:12:45  <auroraeosrose>and yeah - we need the sxsplus library done to get side by side extensions for language extensions loading
17:14:02  <auroraeosrose>eventually it would be GREAT to have x86 and x64 builds for all the libraries in mingw, VC9 (visual studio 2008) vc10 (visual studio 2010) and vc11? (visual studio 2012) flavors
17:16:23  <berdario>ok, auroraeosrose what is the problem of perl's build being monolithic?
17:17:16  <madewokherd>we can't package any additional extensions for it, or select the version/publisher of perl or individual extensions needed by a particular application
17:17:36  <berdario>I mean... even if it's... it should be possible to set it as a dependency of a .pl file, and then install it only one time that a perl-program-packaged-with-coapp is installed, or am I being a little bit optimistic?
17:17:40  <madewokherd>you're stuck with whatever perl is installed and in the path, which may or may not have what you need
17:18:26  <berdario>uhm, do you mean that, perl extensions written in C couldn't be made available to other programs/extensions?
17:18:55  <madewokherd>yes
17:19:01  <berdario>still, is this a problem even for pure perl-extensions? (sorry for an eventual misnomer... I'm not really a perl guy)
17:19:32  <madewokherd>if you want them packaged separately from your program, yes
17:20:02  <madewokherd>(I'm not either)
17:20:56  <berdario>so, madewokherd if I have a program A, that requires a perl extension B, and the perl interpreter itself (C)... I could make a coapp package that contains A and B, and another one that contains C, and make the first one depend on the second... and everything would work fine?
17:22:45  <madewokherd>only if C is the only perl interpreter installed (and ours doesn't have a -dev package so you wouldn't be able to compile a C extension for it)
17:23:18  <madewokherd>well I guess you could change the name of your perl interpreter and select it that way
17:24:14  <berdario>uhm, what is the problem of having multiple interpreters installed?
17:24:31  <madewokherd>you can only have one binary named "perl" in your path
17:24:48  <berdario>I mean: does Coapp specifies something for invoking an external process? (putting the interpreter in the PATH?)
17:24:52  <berdario>ok
17:25:00  <madewokherd>not yet
17:25:19  <madewokherd>if you install perl-monolithic, its perl binary will be in your path
17:25:25  <berdario>so... if every coapp package uses the same interpreter version, and they don't require C extensions, everything should be fine?
17:25:46  <madewokherd>yes
17:25:51  <berdario>good :)
17:26:07  <madewokherd>until perl-monolithic is obsolete and your package breaks because there are new perls
17:26:25  <berdario>yeah... actually I'm more interested in Python
17:26:35  <madewokherd>me too
17:26:48  <berdario>I don't know about Perl... but if I write a Python3 program, it should work fine for several years to come
17:27:13  <madewokherd>we basically cheated to get perl packaged, and since python isn't as common a build dependency there's not as much motivation to do the same thing there
17:27:39  <berdario>I mean: what could break, if the coapp Python package is upgraded from python3.2 to python3.3?
17:28:01  <berdario>(obviously, C modules would break... but these are a no-no currently)
17:28:26  <berdario>and if we don't byte-compile each and every python source file upon installation, that shouldn't be a problem, right?
17:28:30  <madewokherd>if you ship a .pyc file that'd be a problem, but you --right
17:29:30  <madewokherd>but personally I'm not planning to package python until I can do it right
17:29:51  <berdario>ok, I might be wrong, but I don't think that byte-compiling upon install (like debian does e.g.) is really worth the hassle, isn't it? the downside of not doing that is that it would be done a time for each user that uses the python program on the first time... but that's it, no?
17:30:26  <madewokherd>no, if you don't have write access to the directory containing the .py file (and you won't), you'll have to do that every time
17:30:47  <berdario>Ok, I actually already have clone the Python3.2 coapp fork... are you Hamish C?
17:30:54  <madewokherd>no
17:30:59  <madewokherd>HamishC is Hamish C
17:31:31  <berdario>lol, right... I wasn't looking at the channel connected users ^^
17:33:17  <madewokherd>we probably will skip byte-compiling at first; better to get things working before thinking about optimizations
17:34:50  <madewokherd>and this is a hard enough problem as it is
17:39:11  <madewokherd>this would've been much easier if coapp were a "normal" package manager and only planned to have one version of everything, except for all the problems that come with that :p
17:39:38  <berdario>Uhm, weird... I don't know why... but Python3, at least on windows... doesn't return the path of the .pyc when you access .__file__
17:40:07  <berdario>btw, madewokherd... do you know about __pycache__ ? that should make the byte-compiling problem go away, no?
17:40:16  <madewokherd>no
17:40:50  <madewokherd>(no I don't know about it)
17:41:30  <madewokherd>is that a builtin feature?
17:41:46  <berdario>well, since Python3.2, all the .pyc are aggregated in a __pycache__ directory
17:41:47  <berdario>yes
17:42:04  <berdario>it seems it will still create it in the current directory
17:42:10  <berdario>or the module directory
17:42:51  <berdario>this was the page I was looking before
17:42:51  <berdario>http://www.python.org/dev/peps/pep-3147/
17:42:57  <madewokherd>well, it'd have to disambiguate modules with the same name somehow
17:43:29  <madewokherd>we'd pretty much have to do that for anything that's not depending on a specific minor python version
17:43:30  <berdario>I don't think you can have modules with the same name... unless they are in different parent modules
17:43:57  <madewokherd>you can have .py files with the same name and nothing to do with each other, e.g. as part of two separate programs
17:44:09  <madewokherd>or a package of the same module from different publishers
17:44:40  <madewokherd>sxs is needed to choose the right one
17:45:36  <auroraeosrose>ewwww
17:46:47  <berdario>yes, that's true
17:46:51  <berdario>I reread the PEP
17:46:59  <berdario>I was under the impression that __pycache__ was global
17:47:10  <auroraeosrose>ewwwww
17:48:32  <berdario>well... we could just symlink packagedir\__pycache__ to %appdata%\packagedir\__pycache__ no? (while doing the same for each and every module contained in the package?)
17:48:48  <berdario>uhm... no
17:48:52  * auroraeosrose1joined
17:48:56  <berdario>not if the package is installed system-wise
17:49:03  <berdario>argh
17:49:38  * auroraeosrosequit (Disconnected by services)
17:49:59  * auroraeosrose1changed nick to auroraeosrose
17:50:03  * auroraeosrosequit (Changing host)
17:50:03  * auroraeosrosejoined
17:50:20  <madewokherd>we'd pretty much need to store the .pyc file based on a hash of the filename
17:51:01  <madewokherd>then again, we'll already have to mess with the import logic to make it work with sxs anyway, so maybe solving this won't be much more difficult
17:51:05  <berdario>uhm... making the __pycache__ directories writable to all users (or a symlink to %programdata% or %ALLUSERSPROFILE% ) would be a security hole, right?
17:51:13  <madewokherd>right
17:52:47  <berdario>ok, can you elaborate on the need for sxs? I know that it's a nice thing to support... but I thought that it was meant mainly for native C/C++ libraries...
17:53:37  <auroraeosrose>berdario: it is only for native c/c++ stuff
17:53:56  <auroraeosrose>but let's say you want ot install python 2 and 3 - at the same time
17:54:01  <auroraeosrose>and want extensions for both...
17:54:20  <auroraeosrose>C extensions, not just .py files which may be fine ;)
17:54:25  <berdario>ok, so... we could put C modules in sxs, and the .py (and possibly the __pycache__) somewhere else?
17:54:41  <madewokherd>it's really hard to make a non-trivial .py file that works on both 2 and 3
17:54:47  <auroraeosrose>__pycache__ no - that would be tied to a specific python version yes
17:54:50  <auroraeosrose>?
17:55:09  <berdario>auroraeosrose: no, it contains .pyc for every python version
17:55:10  <madewokherd>wherever we put the .py file, we'd have the same problems that sxs solves
17:55:15  <berdario>(minus python < 3.2)
17:55:41  <madewokherd>we need to find the best compatible version of the correct file by the correct publisher, and all of its dependencies
17:56:09  <berdario>madewokherd: sure it's hard... if targeting python 3.x with x<3 it might be impossible... but I don't that's the main problem, is it?
17:56:39  <berdario>s/I don't/I don't think/
17:57:02  <madewokherd>[12:53:43] <madewokherd> it's really hard to make a non-trivial .py file that works on both 2 and 3 <-- not really a relevant comment, just felt the need to answer whether the same py file would be find on both
17:57:16  <berdario>ok, sure
17:58:24  <berdario>so, if I understood correctly... madewokherd thinks it's better to keep the .pyc in the sxs as well... while auroraeosrose maybe doesn't?
17:58:34  <auroraeosrose>?
17:58:40  <madewokherd>?
17:58:48  <auroraeosrose>pyc would NOT go into SxS
17:58:52  <auroraeosrose>SxS is ONLY for assemblies
17:58:54  <berdario>eh, I'm trying to understand what's the consensus :P
17:59:06  <berdario>ok
17:59:06  <auroraeosrose>but we might have to keep the right pyc file with it's binary
17:59:16  <auroraeosrose>which means controlling where they're placed
17:59:32  <madewokherd>if an extension is for a specific minor python version, it could make sense to put the pyc file there, but it might not be worth the effort to do it
17:59:49  <berdario>madewokherd wrote " wherever we put the .py file, we'd have the same problems that sxs solves", and I assumed that the logical consequence was: "thus we might as well try to put the .pyc inside sxs"
17:59:59  * piscisaureus_quit (Ping timeout: 244 seconds)
18:00:18  <madewokherd>no, it's "thus we might as well use sxs to solve those problems for .py files instead of inventing a new thing"
18:00:48  <berdario>madewokherd: now you're talking about plain human-readable .py files... is that correct?
18:01:11  <madewokherd>yes
18:01:47  <madewokherd>I'm not sure how useful it is to talk about where to put .pyc files until we have a solution for .py files
18:01:58  * auroraeosroseshrugs
18:02:01  <berdario>use sxs to solve problems with .py files, that are in the vast majority of cases forward compatible with the next python versions?
18:02:25  <madewokherd>?
18:02:26  <auroraeosrose>I'm confused - why should coapp solve that issue - it shouldn't right?
18:03:00  <auroraeosrose>if I have a PHP library (not extension, but scripts) I will have multiple versions of that library for different PHP versions...
18:03:08  <auroraeosrose>if it's not compatible
18:03:12  <auroraeosrose>(usually it is)
18:03:44  <madewokherd>only coapp will have the dependency information to say what versions of python are compatible
18:04:15  <berdario>madewokherd: I don't follow you
18:04:26  <berdario>I think that in the case of .py files that's not a problem
18:05:12  <berdario>I mean: if a .py file isn't compatible with a python version... chances are that the only version of the file that will work with the old python, is an old version of the file itself
18:05:20  <madewokherd>until we have feature support we pretty much have to lock everything to a specific minor version anyway
18:05:49  <berdario>if we use coapp for a simple use case of: "always install the latest stable/unstable version of the software". we shouldn't care about that?
18:05:54  <berdario>(but maybe we do care)
18:06:08  * piscisaureus_joined
18:06:15  <madewokherd>not everyone will necessarily update their packages
18:07:01  <madewokherd>and that burden shouldn't be there; if you package your program with coapp then nothing we do should break it
18:07:09  <berdario>madewokherd: that shouldn't be a problem
18:07:36  <berdario>I mean: assume that we have a python3 package, and there's A who depends on python3.2 and B who depends on python3.3
18:07:50  <madewokherd>ok
18:08:06  <berdario>in debian we would have something like a python3 metapackage, and then a python3.2 package and a python3.3 package
18:08:41  <berdario>if the user installs A and python3.2, and then tries to install python3.3, it should automatically fetch the new version of the interpreter, and everything should continue to work merrily, or not?
18:09:15  <berdario>s/install python3.3/install B who depends on python3.3/
18:09:24  <madewokherd>we don't currently have the ability to distinguish at runtime between A depending only on python 3.2, and A depending on python 3.2 AND an extension module for python 3.2
18:10:02  <berdario>ok
18:10:05  <madewokherd>or I guess at install time
18:10:07  <madewokherd>once we have that, it'll be possible to say "I just need some python 3.x interpreter", but we're not there yet
18:10:36  <berdario>yes, but still... this it's not a problem with .py files
18:10:52  <berdario>it's again the problem of having C modules...
18:11:00  <madewokherd>a .py file can easily depend on a C extension
18:11:05  <berdario>sure
18:11:31  <madewokherd>and I don't think it's impossible to break on a new minor python version
18:11:32  <berdario>what I mean is: coapp could be feasible for now, if we ship only pure python programs
18:11:40  <madewokherd>though I'm not sure how you would do it
18:11:55  <berdario>or if we ship a monolithic python interpreter that bundles some of the most commons C modules
18:12:31  <madewokherd>sure, but then we'd have to go back and break that when we package python properly
18:12:56  <berdario>sure, but that would be the same as what's happening with perl, no? :)
18:13:12  <madewokherd>there's a reason we're telling people not to use perl for their applications
18:13:14  <berdario>besides... it might be useful to spark some interest in coapp for other python developers imho
18:13:18  <madewokherd>it's just so we can get things built for now
18:14:07  <berdario>ok, so coapp actually doesn't want interest from scripting languages developers, because it would be a mess to sort this out later, when doing things properly
18:15:10  <madewokherd>unless they can get these things supported faster, but FearTheCowboy doesn't seem to be able to use the help :/
18:15:46  <berdario>what do you mean by "use the help"?
18:16:03  <berdario>lack of documentation? lack of code review and merging the changes?
18:17:45  <madewokherd>what's currently blocking proper python support is work that only he knows how to do, and he doesn't seem able to use help from anyone else on it, at least until it's further along
18:18:39  <auroraeosrose>what is currently blocking proper anything with extensions support is the sxsplus library stuff ;) and yes I think I can count on one hand the number of people who understand that ;)
18:20:02  <madewokherd>then again, we are planning to do essentially the thing berdario described with php, aren't we?
18:20:06  <berdario>is it hard? or is it just reaaaally boring to try to understand all the things needed for sxsplus? (or... again: documentation is lacking?)
18:21:20  <auroraeosrose>berdario: the only people who understand the side by side stuff are the guys at microsoft who wrote it
18:21:23  <auroraeosrose>hence - no documentation
18:21:47  <madewokherd>apparently there is documentation but it only makes sense if you already know how sxs works
18:21:51  <auroraeosrose>(this is C, C++ stuff) - you can try to dig around online to see what you can find ...
18:22:02  <auroraeosrose>yeah... and black voodoo magic is the real word for it
18:22:11  <auroraeosrose>now we can do builds of PHP and python with just the basics
18:22:22  <auroraeosrose>they just won't be able to do C extensions right
18:22:24  <auroraeosrose>which ... sucks
18:27:45  <berdario>uhh, ok :/
18:29:55  <berdario>ok, I'm still not persuaded about this: "auroraeosrose> but we might have to keep the right pyc file with it's binary"
18:30:25  <auroraeosrose>berdario: pyc - this is a compiled file correct? can you use the same pyc file with different versions of python?
18:30:31  <berdario>I mean... we'd have to either link every .pyc to the correct file inside sxs... or change the code that cpython uses for importing modules
18:30:39  <berdario>auroraeosrose: no
18:30:41  <auroraeosrose>if you can we're ok, if you CAN'T you need to differentiate
18:31:08  <berdario>but the filename of a .pyc, since Python3.2 is different
18:31:17  <berdario>so python3.3 won't pick the 3.2 pyc and viceversa
18:31:55  <auroraeosrose>yeah
18:32:40  <berdario>e.g we would have one.cpython-32.pyc and one.cpython-33.pyc, and that's the default behaviour of python
18:33:01  <berdario>but, even with .dll
18:33:20  <berdario>(I guess that python C modules are .dlls on windows, right?)
18:33:30  <berdario>it would be a mess, to implement
18:34:12  <berdario>(I'll look a little bit into some bird's view overview of sxs... I only have a vague idea of how does it work)
18:35:44  <auroraeosrose>berdario: yes python c modules are .dlls on windows
18:35:55  <auroraeosrose>sxs will make sure a dll matches properly before loading
18:37:11  <madewokherd>we have to change the importing code anyway to search sxs
18:38:00  <auroraeosrose>yup
18:38:34  <auroraeosrose>basically berdario instead of taking a filepath for loadlibrary
18:40:04  <auroraeosrose>instead you send info about the assembly you want to the side by side cache ;) and it gives you the right thing
18:40:50  <auroraeosrose>For applications that have been built with SxS, multiple applications may coexist that depend on different versions of the same DLL. This is in contrast to non-SxS DLL environments where an original DLL in a shared system folder may be overwritten by the subsequent installation of another program that depends on a different version of the same DLL.
18:41:00  <auroraeosrose>this - this is why I love SxS ;)
18:41:14  <berdario>ok, so it's needed to change the importing code...
18:41:58  <berdario>but weird... I looked again at the wikipedia article:
18:42:01  <auroraeosrose>basically just replace the loadlibrary with a sxs aware loadlibrary
18:42:13  <berdario>However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name, which means that different versions of one DLL will technically be completely different DLLs now.[1][2]
18:42:33  <auroraeosrose>ah, that's more microsoft nonsense
18:42:56  <ender`>that sounds like they went with the libtool solution :)
18:43:09  <auroraeosrose>the visual studio developers, the .NET developers, the office developers, and the windows core developers all have different ideas of where things are going
18:43:11  <berdario>eh... it's making myself doubt that they might want to avoid sxs in the future :/
18:43:17  <auroraeosrose>and heaven forbid they communicate
18:43:37  <auroraeosrose>just like the COM thing
18:43:48  <auroraeosrose>"com is deprecated" then winrt comes out and is entirely com
18:43:49  <berdario>yeah, I heard of that problem... but sooner or later, they'll have to communicater, and decide on a common approach
18:43:53  <auroraeosrose>so damn funny
18:44:05  <auroraeosrose>I tend to trust the windows core devs cause frankly, they have the control
18:44:42  <berdario>ok, so: WinRT: not core, VS devs: not core, Winsxs devs: core... right?
18:44:50  <auroraeosrose>yup
18:45:01  <berdario>good, that's restores some hope :)
18:45:17  <berdario>s/that's/that
18:52:01  <berdario>finished downloading VS \o/
18:52:19  <berdario>gosh, 8.85 GB required
18:54:57  <auroraeosrose>heh, you can turn some stuff off
18:55:03  <auroraeosrose>I generally dont' install any of the VB stuff
18:55:23  <berdario>auroraeosrose: even if I select the 2nd disk... it still wants to install on C: ...I have slightly less than 5GB free on C: (it's a 30GB ssd)
18:55:42  <berdario>I can skip the MFC, right?
18:56:00  <berdario>(if I skip it, it'll barely fit)
18:56:02  <auroraeosrose>oh wow - that's gonna run like crap if you have so little free space
18:56:18  <auroraeosrose>and yeah, you can skip lots
18:56:59  <berdario>well, I hope it won't run like crap... it shouldn't
18:57:10  <berdario>btw, installing now
18:58:10  <berdario>weird... if I move the install window... where's the white ribbon logo... I get some green ghosting
20:01:50  <berdario>Bah, I still have the same problem as before when trying to install the windows sdk :(
20:21:49  * piscisaureus_quit (Read error: No route to host)
20:22:35  * piscisaureus_joined
20:33:28  <berdario>maybe I'll try again tomorrow on my other machine (a netbook :/)
20:58:50  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:47:31  * ender`quit (Quit: foot, n. a device used for finding Lego bricks in the darkness)