<arigato>
nanonyme: about "...": you can ignore that in your case, because the Windows API is designed to be ABI-stable
<nanonyme>
arigato, yeah, I was mainly wondering if I can be lazy when declaring the functions
<arigato>
not the functions, but you can be lazy when declaring a large struct when you don't need most of the fields
<nanonyme>
arigato, also, does set_unicode take care of defining UNICODE constant so compiler will consider CreateFile to be CreateFileW?
<arigato>
yes
<nanonyme>
Cool
<nanonyme>
I should really write some test suite for at least some of this so it won't publish to PyPI even if the functions aren't actually accessible
<njs>
nanonyme: I suggested it in #twisted earlier :-)
<arigato>
I just googled "cffi windows api"
<arigato>
I wouldn't be surprized if there is already more than one
<njs>
it's extremely easy to forget that step :-(
<nanonyme>
njs, I somehow missed it
<nanonyme>
arigato, yeah, my bad. It was the fifth hit after CFFI docs
<njs>
I suspect it's not a simple replacement for what you want anyway, but it's a useful reference if nothing else
<nanonyme>
I just want access to the WinAPI functions from Python in a way that I don't have to declare everything with ctypes. That's exhausting
<nanonyme>
That's actually less thin of a layer I was thinking of, he apparently even bothered writing Python-side code
<nanonyme>
Ugh, I'll delete the stuff from PyPI once I reboot back to Linux
<arigato>
maybe there isn't a cffi project doing *just* the layer over the windows API, in that case your project is useful :-)
<arigato>
I wonder if large parts of that API are not available somewhere in some preprocessed format (instead of .h files)
<njs>
when I looked at it there was a lot of... stuff there, I wanted like 10% of it plus another 20% that wasn't there, so it seemed simplest to just do my own thing. cffi does make it pretty easy to do.
<arigato>
...or, well: I believe there is likely already one of the binding generators for cffi that can input Windows.h
<arigato>
I mean I *guess* there is
<arigato>
binding generators are tools written on top of cffi that input real .h files and turn them into cdef()
<njs>
there's probably some awkward copyright issue there too
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
<nanonyme>
njs, are you referring with copyright problems that you're statically linking against various Microsoft libraries?
<nanonyme>
And then shipping resultant binary
<njs>
nanonyme: no, I was talking about sucking in Windows.h and converting it into a chunk of cffi code
<nanonyme>
Ah
<njs>
nanonyme: obviously in practice no-one is going to complain about copying some prototypes off MSDN but there is some IP question there probably
<nanonyme>
Yeah, I started wondering about that while writing my bindings
<nanonyme>
As in, yes, *my* parts are under MIT but my parts were by far inferior parts of the bindings
<nanonyme>
What is the rest licensed under?
<nanonyme>
But yeah, on API-level you also have the issue that you statically link against other libraries. Using MIT might be fine, maybe. I'm pretty sure using GPL and shipping the result would violate the license Microsoft licenses their static libraries under though
<njs>
what static linking are you referring to?
<nanonyme>
Eg Kernel32.lib
<njs>
you're not statically linking against e.g. kernel32.dll
<nanonyme>
If you're using API-level, you use Kernel32.lib, not Kernel32.dll
<njs>
eh, kernel32.lib is just a big table listing all the functions in kernel32.dll
<nanonyme>
Right. Anyway, it's static linkage and license concerns apply
<njs>
GPL says you can use proprietary stuff if it's part of the platform you're targeting, so linking against kernel32.dll is fine
<njs>
and linking against kernel32.lib is just the windows linker's weird mechanism for dynamically linking against kernel32.dll, there's no actual code in kernel32.lib
<nanonyme>
njs, where? I've never heard of that
aboudreault has quit [Excess Flood]
<nanonyme>
As in, the GPL bit
<nanonyme>
For the latter I find that totally believable
girish946 has quit [Ping timeout: 255 seconds]
<njs>
nanonyme: for the gplv2 it's this clause: "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs [...]"
aboudreault has joined #pypy
<nanonyme>
Ah
<nanonyme>
But yeah, the lib->dll sounds totally plausible as anything else would be a maintenance hell
<nanonyme>
Microsoft probably wants to be capable of fixing bugs for everyone by just shipping a new kernel32.dll
<njs>
(and in v3 there's a similar bit about "system libraries" being allowed to be closed source)
<njs>
yeah, windows has no stable syscall abi
<njs>
the stable abi is the first layer of dll's on top, like kernel32.dll
<nanonyme>
Anyway, all in all, it seems like I should mostly just contribute to pywincffi to make sure it has the parts I need if it's missing something
girish946 has joined #pypy
tilgovi has quit [Ping timeout: 260 seconds]
<nanonyme>
We need occasionally some slightly exotic parts of WinAPI
vkirilichev has joined #pypy
<fijal>
hi
marr has quit [Ping timeout: 240 seconds]
nimaje is now known as Guest83209
Guest83209 has quit [Killed (card.freenode.net (Nickname regained by services))]
nimaje has joined #pypy
<nanonyme>
njs, and yeah, I can't really just target those specific ones easily since what's needed might often change so it's best to just have as complete bindings as possible. win32api was one but it has a lot of downsides
girish946 has quit [Read error: Connection reset by peer]
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
vkirilichev has quit [Remote host closed the connection]
vkirilichev has quit [Remote host closed the connection]
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #pypy
amaury has joined #pypy
ansichart has joined #pypy
aboudreault has quit [Excess Flood]
tilgovi has joined #pypy
<ansichart>
Hello, I am building pypy from source and finished packaging it to a .tar.bz2 package... When I unpack it, everything is under the "pypy-VER-PLATFORM" directory. Is it recommended to do a "mv pypy-VER-PLATFORM/* ./" so that /usr/local/ is the base, so I don't need to reconfigure my PATH variable?
<ansichart>
since I originally unpacked it in /usr/local
<ansichart>
My only concern is that if I do that, it might get mixed up with other things I install under /usr/local/
aboudreault has joined #pypy
<mattip>
ansichart: in typical use, you will not add pypy-VER-platform to your path, rather simply run pypy with its full path as an executable
<mattip>
plan_rich: I tried tracking down the line that hangs, it seems to be in the call to vmp_scan_profile (or rather the call to dump_native_signals which calls the former)
<mattip>
will try to play more tomorrow
mattip has left #pypy ["bye"]
vkirilichev has joined #pypy
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
<ansichart>
I need to rebuild pypy from source with the "--shared" option, in order to get mod_wsgi to work. Do I need to clear anything out if rebuilding with the rpython scrip?