Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73677 > unrolled thread

What can Nuitka do?

Back to article view | Back to comp.lang.python

Contents

  What can Nuitka do? CM <cmpython@gmail.com> - 2014-06-27 16:25 -0700
    Re: What can Nuitka do? Paul Sokolovsky <pmiscml@gmail.com> - 2014-06-28 02:44 +0300
      Re: What can Nuitka do? Rustom Mody <rustompmody@gmail.com> - 2014-06-27 19:10 -0700
        Re: What can Nuitka do? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-28 03:09 +0000
          Re: What can Nuitka do? CM <cmpython@gmail.com> - 2014-06-27 20:44 -0700
            Re: What can Nuitka do? Michael Torrie <torriem@gmail.com> - 2014-06-27 22:14 -0600
            Re: What can Nuitka do? Chris Angelico <rosuav@gmail.com> - 2014-06-28 15:00 +1000
            Re: What can Nuitka do? "Gisle Vanem" <gvanem@yahoo.no> - 2014-06-28 12:39 +0200
              Re: What can Nuitka do? Roy Smith <roy@panix.com> - 2014-06-28 11:35 -0400
            Re: What can Nuitka do? Chris Angelico <rosuav@gmail.com> - 2014-06-29 01:16 +1000
            Re: [OT] What can Nuitka do? Michael Torrie <torriem@gmail.com> - 2014-06-30 07:10 -0600
            Re: [OT] What can Nuitka do? Chris Angelico <rosuav@gmail.com> - 2014-06-30 23:36 +1000
            Re: [OT] What can Nuitka do? Michael Torrie <torriem@gmail.com> - 2014-06-30 22:17 -0600
            Re: [OT] What can Nuitka do? Michael Torrie <torriem@gmail.com> - 2014-06-30 22:26 -0600
      Re: What can Nuitka do? CM <cmpython@gmail.com> - 2014-06-27 20:06 -0700
        Re: What can Nuitka do? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-28 03:17 +0000
          Re: What can Nuitka do? CM <cmpython@gmail.com> - 2014-06-27 20:57 -0700
            Re: What can Nuitka do? Rustom Mody <rustompmody@gmail.com> - 2014-06-27 21:11 -0700
            Re: What can Nuitka do? Stefan Behnel <stefan_ml@behnel.de> - 2014-06-28 06:23 +0200
              Re: What can Nuitka do? CM <cmpython@gmail.com> - 2014-06-27 21:45 -0700
                Re: What can Nuitka do? Chris Angelico <rosuav@gmail.com> - 2014-06-28 15:02 +1000
                  Re: What can Nuitka do? CM <cmpython@gmail.com> - 2014-06-27 22:40 -0700
                    Re: What can Nuitka do? Chris Angelico <rosuav@gmail.com> - 2014-06-28 16:16 +1000
                    Fwd: What can Nuitka do? Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-06-28 09:45 +0200
        Re: What can Nuitka do? Michael Torrie <torriem@gmail.com> - 2014-06-27 21:28 -0600
          Re: What can Nuitka do? Rustom Mody <rustompmody@gmail.com> - 2014-06-27 20:40 -0700

Page 1 of 2  [1] 2  Next page →

#73677 — What can Nuitka do?

(Trying again, simpler and cleaner post)

Can I use Nuitka to transform a wxPython 
GUI application in Python that uses several
3rd party modules into a small and faster
compiled-to-C executable?

[toc] | [next] | [standalone]

#73680

Hello,

On Fri, 27 Jun 2014 16:25:02 -0700 (PDT)
CM <cmpython@gmail.com> wrote:

> (Trying again, simpler and cleaner post)
> 
> Can I use Nuitka to transform a wxPython 
> GUI application in Python that uses several
> 3rd party modules into a small and faster
> compiled-to-C executable?

Yes, you can. So, please try that, and report how that went. We're
eager to know how that would go very much. But unlike you, we don't
have need to transform wxPython GUI application in Python into
an executable. So, you are in the best position to answer your question.

And surprisingly, both Nuitka and PyPy are free, so you won't need to
shell out few $Ks to try it, or wear your suit, hop on the plane, and
go to another side of the country (or world) and spend many hours in
negotiations to get an evaluation license. Just download and try.
Unbelievable, how world has changed in some 30-40 years!



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

[toc] | [prev] | [next] | [standalone]

#73684

On Saturday, June 28, 2014 5:14:39 AM UTC+5:30, Paul Sokolovsky wrote:
> Hello,

> On Fri, 27 Jun 2014 16:25:02 -0700 (PDT)
> CM wrote:

> > (Trying again, simpler and cleaner post)
> > Can I use Nuitka to transform a wxPython 
> > GUI application in Python that uses several
> > 3rd party modules into a small and faster
> > compiled-to-C executable?

> Yes, you can. So, please try that, and report how that went. We're
> eager to know how that would go very much. But unlike you, we don't
> have need to transform wxPython GUI application in Python into
> an executable. So, you are in the best position to answer your question.

> And surprisingly, both Nuitka and PyPy are free, so you won't need to
> shell out few $Ks to try it, or wear your suit, hop on the plane, and
> go to another side of the country (or world) and spend many hours in
> negotiations to get an evaluation license. Just download and try.
> Unbelievable, how world has changed in some 30-40 years!


All true...
However programming is engineering and programmers can suffer severe
paradox of choice if there's too much to choose from.

Going back along a different track by a couple of decades:

20 years ago python pushed the envelope of being a sweet combination of
being a serious system programming+lightweight scripting language at the same
time.

Today there are other choices¹:

- There are new languages that outright set out to be be as
efficient as C/FORTRAN -- eg Julia.

- A whole crop of new languages that are striving to plough back (some of)
scripting convenience into the compiled language mold -- eg Swift, Go

Languages that handle modern multicore hardware appropriately -- Erlang

And finally functional programming has come of age. So eg one of Haskell's
agendas is to beat C/Fortran's performance:

| Remarkably, our benchmarks show that choosing the proper stream
| representations can result in machine code that beats
| compiler-vectorized C, and that is competitive with hand-tuned
| assembly. --
|   From  http://research.microsoft.com/en-us/um/people/simonpj/papers/ndp/haskell-beats-C.pdf

tl;dr:

If no one speaks up (with hard specific data!) for the technologies
you are considering (eg PyPy, Nuitka etc) then I would conclude that
they are not yet ready for prime-time/ your use-case


¹ Yeah that seemingly adds to the paradox of choice problem!!

[toc] | [prev] | [next] | [standalone]

#73686

On Fri, 27 Jun 2014 19:10:25 -0700, Rustom Mody wrote:

> If no one speaks up (with hard specific data!) for the technologies you
> are considering (eg PyPy, Nuitka etc) then I would conclude that they
> are not yet ready for prime-time/ your use-case

A silly conclusion. The OP's use-case is quite specific, namely he wants 
to freeze a wxPython GUI app in a single executable *and* optimize it, 
while this mailing list is very general. Most people here are not experts 
on *any* of Nuitka, PyPy, wxPython or freezing applications, let alone 
all of them. Lack of hard specific evidence is not evidence that the job 
cannot be done, it's just evidence that the people here don't know how.

Having said that, I think that the OP's question is probably misguided. 
He or she gives the impression of expecting PyPy or Nuitka to be a magic 
button that will speed up the user experience, like the Turbo button on 
old PCs. (Remember them?) It's not likely to be that easy.

wxPython is a wrapper to a C GUI library, all the work is done in C, not 
Python, so moving to PyPy or Nuitka won't speed it up. It may even slow 
it down, if the interpreter is less efficient at calling C libraries.

Additionally, in most GUI apps (although not all), the main bottleneck is 
usually not the programming language but the user. GUI apps tend to spend 
95% of their time idling, waiting for the user. Its been a *long* time 
since the GUI framework itself has lagged behind the user's input, except 
in cases of memory exhaustion. So if the OP is interested in speeding up 
his or her application, the first thing to do is to identify what parts 
of it are slow, identify why they're slow, and concentrate on those parts.

For example, if the OP's app is slow because it repeatedly scans a remote 
network directory, then moving to PyPy won't speed it up, because file 
operations over a network are inherently slow. If it's slow because it 
foolishly uses bubble sort to sort 1000 items instead of Python's built-
in sort, then moving to PyPy may technically speed it up, but probably 
not enough to notice.

Some problems are inherently slow. Some are fixable by using better 
algorithms. And some are fixable by using an optimizing compiler like 
PyPu or Nuitka. We are given no reason to think that the OP's problems 
lie in that third area rather than the first two.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#73691

On Friday, June 27, 2014 11:09:11 PM UTC-4, 
Steven D'Aprano wrote:
 
> Having said that, I think that the OP's question 
> is probably misguided. 

Thanks, Steven, for the input. It very well might be.  
I'll give a little more information.
 
> He or she gives the impression of expecting PyPy 
> or Nuitka to be a magic button that will speed up 
> the user experience, like the Turbo button on 
> old PCs. (Remember them?) It's not likely to be 
> that easy.

I'm sure it does give just that impression. I'll 
admit that if it *did* do something like that, I'd
be pleased, of course. But I expected it not to work
so well as that, or perhaps not work at all. Really,
I asked more out of curiosity, since these projects
keep staying out there but I rarely read about people
actually using them.  They seem more like proof of
principle intellectual work, but I really know not of
what I speak, and so was trying to get more 
understanding. I also thought it may be helpful in
creating a standalone executable (instead of using
the various ways to do that with Python, which I am
familiar with and have done successfully), and wanted
to see if there were any advantages to that (such as
a smaller file size).

> wxPython is a wrapper to a C GUI library, all the 
> work is done in C, not Python, 

There are some pure Python widgets in wxPython, such
as many or perhaps all within the AGW subdirectory, 
which are some really nice contributions by Andrea
Gavana.  And I believe it's a C++ library, not C.


> so moving to PyPy or Nuitka won't speed it up. 

It may not; I really wasn't sure and thought I'd 
give it a try and see what happened (if it wasn't
a major undertaking to give it a try).

> Additionally, in most GUI apps (although not all), 
> the main bottleneck is usually not the programming 
> language but the user. GUI apps tend to spend 
> 95% of their time idling, waiting for the user. Its 
> been a *long* time since the GUI framework itself 
> has lagged behind the user's input, except 

Although that is true, I have found that I have
managed to get wxPython apps to feel laggy in certain
parts, particularly on not-very-fast computers. I
can see this in starting up the program and some
other areas such as repainting damaged windows
rapidly. It's not a huge effect, but it does 
influence the "look and feel" and I care about it.

> except in cases of memory exhaustion. 

Maybe this is a key issue on one of the older
laptops I was testing on.  The thing is, though,
there are still a lot of SLOW computers out there
in userland, sadly, and doing what one can to 
mitigate the laggy UX by speeding up the program
seems like a virtuous goal. 

> his or her application, the first thing to do is 
> to identify what parts of it are slow, identify 
> why they're slow, and concentrate on those parts.

That's underway, and helping.  I just idly thought
about the state of compilers and JIT and such and
wondered.

[toc] | [prev] | [next] | [standalone]

#73694

On 06/27/2014 09:44 PM, CM wrote:
>> Additionally, in most GUI apps (although not all), 
>> the main bottleneck is usually not the programming 
>> language but the user. GUI apps tend to spend 
>> 95% of their time idling, waiting for the user. Its 
>> been a *long* time since the GUI framework itself 
>> has lagged behind the user's input, except 
> 
> Although that is true, I have found that I have
> managed to get wxPython apps to feel laggy in certain
> parts, particularly on not-very-fast computers. I
> can see this in starting up the program and some
> other areas such as repainting damaged windows
> rapidly. It's not a huge effect, but it does 
> influence the "look and feel" and I care about it.

I highly doubt this lagginess has anything to do with Python, honestly.
 If you're seeing slowdowns in the areas you state, you'll probably
experience the same issues in the equivalent C++ version.  All drawing
is done by the underlying binary library.

I've made GUIs in GTK and Qt with Python and never had any that was
appreciably slower than C or C++ apps.

[toc] | [prev] | [next] | [standalone]

#73697

On Sat, Jun 28, 2014 at 2:14 PM, Michael Torrie <torriem@gmail.com> wrote:
> On 06/27/2014 09:44 PM, CM wrote:
>>> Additionally, in most GUI apps (although not all),
>>> the main bottleneck is usually not the programming
>>> language but the user. GUI apps tend to spend
>>> 95% of their time idling, waiting for the user. Its
>>> been a *long* time since the GUI framework itself
>>> has lagged behind the user's input, except
>>
>> Although that is true, I have found that I have
>> managed to get wxPython apps to feel laggy in certain
>> parts, particularly on not-very-fast computers. I
>> can see this in starting up the program and some
>> other areas such as repainting damaged windows
>> rapidly. It's not a huge effect, but it does
>> influence the "look and feel" and I care about it.
>
> I highly doubt this lagginess has anything to do with Python, honestly.
>  If you're seeing slowdowns in the areas you state, you'll probably
> experience the same issues in the equivalent C++ version.  All drawing
> is done by the underlying binary library.
>
> I've made GUIs in GTK and Qt with Python and never had any that was
> appreciably slower than C or C++ apps.

Agreed, and there's a fairly easy way to test it (at least, under
Linux): just look in 'top' and see if a significant proportion of the
time is spent in a process called Xorg rather than your python
process. The last time I had a program that could actually saturate a
thread with GUI API calls, it generally ended up split somewhere
between 25% and 75% across my process and Xorg. (Best I could do just
now, in testing, was to hold PgUp/PgDn in an unoptimized program that
repainted the screen immediately whenever it needed to. According to
top, I was using 52% of a core in Xorg, and about 16% of a core in my
code. With a slower computer, that would work out to 75% Xorg and 25%
high level code.) At that point, changing language won't affect
performance one iota, and certainly changing Python interpreter won't
do anything for you. The way to improve performance is to cut out some
of the drawing calls. (The saturation problem came because the code
was naively trying to draw a whole lot of stuff that was hidden behind
a scroll viewport. Adding a quick check "is this sorta close to the
screen" gave me all the improvement I needed.)

The only other time I've been waiting for X display was when I was
mobile, on a 3G connection, and using X11 forwarding on an SSH link
back to my home LAN. For some reason, displaying a remote desktop view
of a VM takes quite a while when every pixel has to be sent over 3G...
but, again, no Python code performance involved :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#73706

"Chris Angelico" <rosuav@gmail.com> wrote:

> The only other time I've been waiting for X display was when I was
> mobile, on a 3G connection, and using X11 forwarding on an SSH link
> back to my home LAN. 

Doing X11 calls over a network could really be a nuisance for others. And 
an archaic design IMHO.

I remember approx. 10 years ago a neighboring dept. at my work effectively 
killed our 10 MB/s Ethernet segment with such traffic (due to a misconfigured 
switch/router?). Running an ethernet analyzer showed a single X11 host-server 
session occupied ~80% bandwidth.  AFAICR, it was a Sun workstation.
A real PITA.

--gv

[toc] | [prev] | [next] | [standalone]

#73708

In article <mailman.11309.1403968204.18130.python-list@python.org>,
 "Gisle Vanem" <gvanem@yahoo.no> wrote:

> "Chris Angelico" <rosuav@gmail.com> wrote:
> 
> > The only other time I've been waiting for X display was when I was
> > mobile, on a 3G connection, and using X11 forwarding on an SSH link
> > back to my home LAN. 
> 
> Doing X11 calls over a network could really be a nuisance for others. And 
> an archaic design IMHO.
> 
> I remember approx. 10 years ago a neighboring dept. at my work effectively 
> killed our 10 MB/s Ethernet segment with such traffic (due to a misconfigured 
> switch/router?). Running an ethernet analyzer showed a single X11 host-server 
> session occupied ~80% bandwidth.  AFAICR, it was a Sun workstation.
> A real PITA.
> 
> --gv

NeWS was a technologically better system than X11 (for exactly the 
reasons mentioned above).  It's a pity X11 won.

The idea of NeWS was you push the low-level U/I interaction and 
rendering into the display side.  Better responsiveness, less network 
bandwidth consumed.  Sort of the same thing that's going on with 
javascript apps replacing server side generated HTML these days.

Come to think of it, it's the same idea as IBM-3270 display terminals, 
40 years ago :-)

[toc] | [prev] | [next] | [standalone]

#73709

On Sat, Jun 28, 2014 at 8:39 PM, Gisle Vanem <gvanem@yahoo.no> wrote:
> "Chris Angelico" <rosuav@gmail.com> wrote:
>
>> The only other time I've been waiting for X display was when I was
>> mobile, on a 3G connection, and using X11 forwarding on an SSH link
>> back to my home LAN.
>
>
> Doing X11 calls over a network could really be a nuisance for others. And an
> archaic design IMHO.
>
> I remember approx. 10 years ago a neighboring dept. at my work effectively
> killed our 10 MB/s Ethernet segment with such traffic (due to a
> misconfigured switch/router?). Running an ethernet analyzer showed a single
> X11 host-server session occupied ~80% bandwidth.  AFAICR, it was a Sun
> workstation.
> A real PITA.

Either that was a horribly inefficient X11 connection (as mine was -
the virtual machine sent basically a constantly-updated bitmapped
image to rdesktop, which then couldn't do anything more efficient than
feed that image to the X server), or something was horribly
misconfigured. I've frequently done much more reasonable X11
forwarding, with high success and low traffic; for instance, I have
one Windows computer on which PDF viewing is so broken that it's
actually more efficient to use PuTTY and Xming to run evince on one of
my Linux boxes than to try to get Adobe Reader or equivalent to
actually run under Windows. (Okay, that says more about Windows and
Adobe stupidities than it does about X11 forwarding, but still, it's
not a lot of traffic.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#73745 — Re: [OT] What can Nuitka do?

On 06/28/2014 09:16 AM, Chris Angelico wrote:
>> I remember approx. 10 years ago a neighboring dept. at my work effectively
>> killed our 10 MB/s Ethernet segment with such traffic (due to a
>> misconfigured switch/router?). Running an ethernet analyzer showed a single
>> X11 host-server session occupied ~80% bandwidth.  AFAICR, it was a Sun
>> workstation.
>> A real PITA.
> 
> Either that was a horribly inefficient X11 connection (as mine was -
> the virtual machine sent basically a constantly-updated bitmapped
> image to rdesktop, which then couldn't do anything more efficient than
> feed that image to the X server), or something was horribly
> misconfigured. I've frequently done much more reasonable X11
> forwarding, with high success and low traffic;

Only the most primitive X11 apps are at all fast over network
forwarding.  If the app uses any modern toolkit, then it's basically
just sending a bunch of bitmaps over the wire (changes), which would be
fine, but X11 involves a lot of server round trips.  Forwarding works
fine over SSH on a LAN (compression with -X helps too), but anything
slower than that is very nearly unusable.  I used to run XEmacs over a
modem (I know; I just preferred it to Emacs and I didn't know ViM), and
it worked great with server-side drawing and fonts, as X11 was designed
to do 90s-style.  But now if I need to run X11 apps over a slower link
these days I use OpenNX which dramatically helps by eliminating round
trips, and applying bitmap compression.  But the fact remains X11 kind
of sucks these days, and "network transparency" now basically means a
slightly suckier version of VNC in effect.  RDP protocol is actually
much more efficient than X11 forwarding with modern apps.  So your
rdesktop example is actually not a horribly inefficient X11 connection,
other than the fact that X11 is inefficient.  Honestly once Wayland has
per-app RDP built into it, there'll be no reason at all to cheer for X11.

[toc] | [prev] | [next] | [standalone]

#73746 — Re: [OT] What can Nuitka do?

On Mon, Jun 30, 2014 at 11:10 PM, Michael Torrie <torriem@gmail.com> wrote:
> Only the most primitive X11 apps are at all fast over network
> forwarding.  If the app uses any modern toolkit, then it's basically
> just sending a bunch of bitmaps over the wire (changes), which would be
> fine, but X11 involves a lot of server round trips.  Forwarding works
> fine over SSH on a LAN (compression with -X helps too), but anything
> slower than that is very nearly unusable.  I used to run XEmacs over a
> modem (I know; I just preferred it to Emacs and I didn't know ViM), and
> it worked great with server-side drawing and fonts, as X11 was designed
> to do 90s-style.  But now if I need to run X11 apps over a slower link
> these days I use OpenNX which dramatically helps by eliminating round
> trips, and applying bitmap compression.  But the fact remains X11 kind
> of sucks these days, and "network transparency" now basically means a
> slightly suckier version of VNC in effect.  RDP protocol is actually
> much more efficient than X11 forwarding with modern apps.  So your
> rdesktop example is actually not a horribly inefficient X11 connection,
> other than the fact that X11 is inefficient.  Honestly once Wayland has
> per-app RDP built into it, there'll be no reason at all to cheer for X11.

Hmm. I'm not sure that it's necessarily that bad; I've done 3G-based
X11 forwarding fairly successfully on occasion. Yes, it's potentially
quite slow, but it certainly works - I've used SciTE, for instance,
and I've used some GTK2 apps without problems. What do you mean by
"modern toolkit"?

ChrisA

[toc] | [prev] | [next] | [standalone]

#73771 — Re: [OT] What can Nuitka do?

On 06/30/2014 07:36 AM, Chris Angelico wrote:
> Hmm. I'm not sure that it's necessarily that bad; I've done 3G-based
> X11 forwarding fairly successfully on occasion. Yes, it's potentially
> quite slow, but it certainly works - I've used SciTE, for instance,
> and I've used some GTK2 apps without problems. What do you mean by
> "modern toolkit"?

Modern toolkit is defined as anything that uses client-side rendering.
In the good old days of Motif and Xaw widgets, if a program wanted to
draw, the toolkit would instruct the server to draw primitives.
Rectangles, lines, etc.  Each widget would be created in its own window,
and events would be all handled on the server.  Unfortunately we quickly
hit some limits with that idea, as good and fast as it was.  First of
all, anti-aliased fonts were difficult to accomplish.  There were hacks
to do this early on, but it quickly became apparent that the actual
application could do a better job of it if it would just do the
rendering itself and have the X server draw it.  Not only anti-aliased
fonts, but also when you start talking about wanting to do layered
effects like alpha-blending.  All of this the app could do better and
more efficiently than the X server could, since the X server would have
had to round-trip to the app anyway to get the information since the X
server is in a different process (or different computer) and cannot
access the memory the app is using to store things.  Kieth Packard wrote
some X extensions to allow client-side rendering to be efficient and to
let the X server to handle RGBA images, and to composite them together.

Also, events in modern toolkits are done very differently than the
original X toolkits.  Instead of using multiple windows, clients now
just establish one window and then handle events and figure out what
widgets should receive the events client-side instead of server-side.
This allows handling of things like scrollable canvases.

Anyway, all of this improved the behavior and appearance of
applications.  When used locally, shared memory facilities make X pretty
fast, although latency is still quite high. There's no way to
synchronize frame redraws, so apps tear and stutter when you drag and
resize.  But over a network now, the nature of the X protocol means a
lot of round-trips to the server to do things. This is very apparent
when you run on a very slow connection. You might see widgets get drawn,
then erase, then drawn again.  Using a complex app like firefox, which
has another layer of abstraction over GTK that makes it even worse, is
very difficult on anything less than a LAN.  Or try a Java Swing app!
I've done it on occasion. I'd rather run Xvnc on the remote host and vnc
in than forward X.

FreeNX makes things very usable.
http://en.wikipedia.org/wiki/NX_technology describes how NX works.

I love that X11 apps work over a forward connection.  And I love that I
can run a remote window manager on a local X server if I wanted to.  But
I recognize X has it's problems and I can see how Wayland will
eventually be so much better while still letting me remote apps, which
is essential to me.

[toc] | [prev] | [next] | [standalone]

#73772 — Re: [OT] What can Nuitka do?

I highly recommend the talk by Daniel Stone who used to be a core X.org
developer.  He explains it quite well how X is used currently, and why
it has problems and why they are considered so hard to fix that Wayland
(and Mir) was created.

https://www.youtube.com/watch?v=RIctzAQOe44

One interesting point he made was the X server is no longer network
transparent like it used to be.  It is network capable now but when used
in that way (ssh forwarding), it's essentially done in the same way as
VNC, but more poorly because of the way X11 is architected.

[toc] | [prev] | [next] | [standalone]

#73685

On Friday, June 27, 2014 7:44:39 PM UTC-4, Paul Sokolovsky wrote:
> Yes, you can. So, please try that, and report 
> how that went. We're eager to know how that would 
> go very much. But unlike you, we don't have need 
> to transform wxPython GUI application in Python into
> an executable. So, you are in the best position to 
> answer your question.

I downloaded and installed Nuitka 0.5.2 for Windows, 
but it seems like the entirety of the instructions 
for what I want to do, as shown on the Docs web page, 
is this:

    nuitka --recurse-all program.py

I would need more help than that to try this. I've
never even used MinGW, for example.

[toc] | [prev] | [next] | [standalone]

#73687

On Fri, 27 Jun 2014 20:06:36 -0700, CM wrote:

> On Friday, June 27, 2014 7:44:39 PM UTC-4, Paul Sokolovsky wrote:
>> Yes, you can. So, please try that, and report how that went. We're
>> eager to know how that would go very much. But unlike you, we don't
>> have need to transform wxPython GUI application in Python into an
>> executable. So, you are in the best position to answer your question.
> 
> I downloaded and installed Nuitka 0.5.2 for Windows, but it seems like
> the entirety of the instructions for what I want to do, as shown on the
> Docs web page, is this:
> 
>     nuitka --recurse-all program.py
> 
> I would need more help than that to try this.


I'm not a Windows user, so I can't give detailed step-by-step "mouse over 
this menu, click this button" instructions, but you need to open a 
command line terminal. (command.com or cmd.exe, I forget which, although 
I understand that these days Windows programmers prefer PowerShell.) At 
the prompt, type:

    cd "C:/path/to/where/your/program/lies/"

then hit Enter. (Of course, you don't *literally* type what I showed, you 
the actual path to your program.)

Confirm that your program is there: at the shell prompt, type

   dir


then hit Enter, and make sure you see your program, something_or_other.py.

Now type 

    nuitka --recurse-all something_or_other.py


and hit Enter. What happens?

(Don't be discouraged if there are a bunch of errors.)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#73692

 
> I'm not a Windows user, so I can't give detailed 
> step-by-step "mouse over this menu, click this 
> button" instructions, but you need to open a  
> command line terminal. (command.com or cmd.exe, 

I'm not *quite* that at sea!  :D  Close, but I am
used to using the command line in Windows. 

> Now type 

>     nuitka --recurse-all something_or_other.py
 
> and hit Enter. What happens?

I did that and the message is:

   'nuitka' is not recognized as an internal 
   or external command, operable program or batch file.

which makes sense because some kind of file called 
nuitka is not in my path. What I wasn't sure of is how 
to add it, because I looked in the nuitka folder in 
Python27/Lib/site-packages and there was no file 
called nuitka.py or nuitka.exe within that folder, 
and there were a lot of subfolders but I just didn't 
know what I should do.  

I have used Linux but not in a while and I can't recall
how installing it is different in terms of the OS 
knowing what "nuitka" means in the command line.
(I installed nuitka for Windows via an installer).

Even once I do this, nuitka won't work until I get
MingGW on here, too, but one step at a time.  I'd like
to get it to at least fail at that point first.

But Rustom Mody's comment suggests this may turn out
to be more work than I am willing to do right now...?


> 
> 
> 
> (Don't be discouraged if there are a bunch of errors.)
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

[toc] | [prev] | [next] | [standalone]

#73693

On Saturday, June 28, 2014 9:27:02 AM UTC+5:30, CM wrote:
> > I'm not a Windows user, so I can't give detailed 
> > step-by-step "mouse over this menu, click this 
> > button" instructions, but you need to open a  
> > command line terminal. (command.com or cmd.exe, 

> I'm not *quite* that at sea!  :D  Close, but I am
> used to using the command line in Windows. 

> > Now type 

> >     nuitka --recurse-all something_or_other.py

> > and hit Enter. What happens?

> I did that and the message is:

>    'nuitka' is not recognized as an internal 
>    or external command, operable program or batch file.

> which makes sense because some kind of file called 
> nuitka is not in my path. What I wasn't sure of is how 
> to add it, because I looked in the nuitka folder in 
> Python27/Lib/site-packages and there was no file 
> called nuitka.py or nuitka.exe within that folder, 
> and there were a lot of subfolders but I just didn't 
> know what I should do.  

> I have used Linux but not in a while and I can't recall
> how installing it is different in terms of the OS 
> knowing what "nuitka" means in the command line.
> (I installed nuitka for Windows via an installer).

> Even once I do this, nuitka won't work until I get
> MingGW on here, too, but one step at a time.  I'd like
> to get it to at least fail at that point first.

> But Rustom Mody's comment suggests this may turn out
> to be more work than I am willing to do right now...?

In all fairness, I know nothing of nuitka.
But I see:

- that it is active (in development)
- there are nuitka mailing list(s)...

[toc] | [prev] | [next] | [standalone]

#73695

CM, 28.06.2014 05:57:
>> Now type 
>> 
>>     nuitka --recurse-all something_or_other.py
>>  
>> and hit Enter. What happens?
> 
> I did that and the message is:
> 
>    'nuitka' is not recognized as an internal 
>    or external command, operable program or batch file.
> 
> which makes sense because some kind of file called 
> nuitka is not in my path. What I wasn't sure of is how 
> to add it, because I looked in the nuitka folder in 
> Python27/Lib/site-packages and there was no file 
> called nuitka.py or nuitka.exe within that folder, 
> and there were a lot of subfolders but I just didn't 
> know what I should do.  

There should be a folder Python27/Scripts that contains the executable
programs that Python packages install.

Stefan

[toc] | [prev] | [next] | [standalone]

#73696

On Saturday, June 28, 2014 12:23:03 AM UTC-4, 
Stefan Behnel wrote:

> There should be a folder Python27/Scripts that 
> contains the executable programs that Python packages 
> install.

Thank you, yes, it's there.  But there are two
files:  nuitka (I don't see an extension and
don't know the file type) and nuitka.bat.  I 
added C:/Python27/Scripts/nuitka to the Windows 
path but it still doesn't recognize the name.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web