Re: Changing 'Scripts/*.exe'

[Greg Ewing]

On 4/10/22 10:49 pm, 2qdxy4rzwzuui...@potatochowder.com wrote:

(I could even move
the file to another folder on the original Mac, but that didn't mean
much, because those old file systems were entirely flat (directories and
folders were an illusion maintained by the Finder)


That was only true in the very early days. A proper hierarchical
file system was available as soon as hard disks became common
(around the Mac II era I think?)

However, internally each file on a volume was identified by a
File ID (something a bit like an inode number) and that was
stored in the alias and used as the first means of finding the
file. There was also a pathname stored in the alias, but that
was only used as a backup in case the file couldn't be found
using the File ID.

So a Mac alias was in some ways more powerful than a
symlink, but in other ways less -- e.g. there was no equivalent
to a relative symlink. Also aliases are more like a Windows
shortcut in that they aren't resolved automatically in the
kernel -- programs need to be aware of them and take explicit
action to resolve them.

Things are even more confusing in MacOSX, which has both
aliases *and* symlinks, they behave differently, and the Finder
doesn't tell you which you're looking at. :-(

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Performance issue with CPython 3.10 + Cython

[Andreas Ames]

Hi all,

I am wrapping an embedded application (, which does not use any dynamic
memory management,) using Cython to call it from CPython.  The wrapped
application uses a cyclic executive, i.e. everything is done in the
input-logic-output design, typical for some real-time related domains.
Consequentially, every application cycle executes more or less the very
same code.  As I am still in a prototyping stadium, the wrapped process is
completely CPU-bound, i.e. except of some logging output there is no I/O
whatsoever.

During one second of "application time", I am doing exactly 120 calls into
the application through three Cython-wrapped API functions.  The
application uses some platform-dependent APIs, which I have also wrapped
with Cython, so that there are numerous callbacks into the Python realm per
call into the application. What I am observing now, is that the performance
per "application second" decreases (remember: executing code that does the
same thing on every cycle) and extending the number of loop iterations does
not seem to cause any bound to this decrease.  In the log ouput below, you
can see the GC counts, which look innocent to me.  The "real time" is
measured using "time.time()". The "top" utility does not suggest any memory
leak either.  I am developing on WSL2, but I have checked that this
performance effect also happens on physical machines.  Right now, I am
staring at "kcachegrind", but I have no idea, how to determine time series
for the performance of functions (I am not looking for those functions,
which need the most time, but for those, which consume more and more
execution time).

One more thing to look for could be memory fragmentation, but before that I
would like to ask the experts here for their ideas and experiences and/or
for tools, which could help to find the culprit.

2022-10-04 10:40:50|INFO|__main__   |Execution loop 0 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.06862711906433105 seconds real time.
> 2022-10-04 10:40:51|INFO|__main__   |Execution loop 100 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.08224177360534668 seconds real time.
> 2022-10-04 10:40:52|INFO|__main__   |Execution loop 200 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.08225250244140625 seconds real time.
> 2022-10-04 10:40:53|INFO|__main__   |Execution loop 300 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.10176873207092285 seconds real time.
> 2022-10-04 10:40:54|INFO|__main__   |Execution loop 400 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.10900592803955078 seconds real time.
> 2022-10-04 10:40:55|INFO|__main__   |Execution loop 500 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.12233948707580566 seconds real time.
> 2022-10-04 10:40:56|INFO|__main__   |Execution loop 600 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.14058256149291992 seconds real time.
> 2022-10-04 10:40:58|INFO|__main__   |Execution loop 700 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.14777183532714844 seconds real time.
> 2022-10-04 10:40:59|INFO|__main__   |Execution loop 800 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.15729451179504395 seconds real time.
> 2022-10-04 10:41:01|INFO|__main__   |Execution loop 900 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.17365813255310059 seconds real time.
> 2022-10-04 10:41:03|INFO|__main__   |Execution loop 1000 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.17772984504699707 seconds real time.
> 2022-10-04 10:41:05|INFO|__main__   |Execution loop 1100 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.1955263614654541 seconds real time.
> 2022-10-04 10:41:07|INFO|__main__   |Execution loop 1200 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.20046710968017578 seconds real time.
> 2022-10-04 10:41:09|INFO|__main__   |Execution loop 1300 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.22513842582702637 seconds real time.
> 2022-10-04 10:41:11|INFO|__main__   |Execution loop 1400 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.23578548431396484 seconds real time.
> 2022-10-04 10:41:13|INFO|__main__   |Execution loop 1500 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.24581527709960938 seconds real time.
> 2022-10-04 10:41:16|INFO|__main__   |Execution loop 1600 done. GC
> counts = (381, 9, 3); 1 second of application time corresponds to
> 0.2541334629058838 seconds real time.
> 2022-10-04 10:41:19|INFO

Re: Changing 'Scripts/*.exe'

[2QdxY4RzWzUUiLuE]

On 2022-10-04 at 14:55:36 +1300,
dn  wrote:

> On 04/10/2022 14.10, Meredith Montgomery wrote:
> > r...@zedat.fu-berlin.de (Stefan Ram) writes:
> > 
> >> Meredith Montgomery  writes:
> >>> Wouldn't it be great if it were portable by default?
> >>
> >>   I think under Windows there is a division of software
> >>   suggested by Microsoft, a division of software into
> >>   executable code and data (data may change in time).
> >>
> >>   The executable code is supposed to rest under
> >>   "C:\Program Files" the contents of which cannot be
> >>   modified by user processes easily. Program configuration
> >>   can be stored below "AppData" in the user directory.
> >>   It is supposed to be more secure when executable code
> >>   cannot be modified easily by user processes.
> >>
> >>   So far, Python has decided to ignore this and install
> >>   everything under AppData as I understand it. So one 
> >>   gets neither the security of "Program Files" nor the
> >>   possibility to move it to another directory easily.
> > 
> > Interesting.  I like portable things.  You copy from one place to
   ^
Copy what?  That's the crux of it.

On vintage (1980s? 1990s? way before OS X, anyway) Mac OS, I could copy
an alias (Mac's version of a symbolic link) to a floppy disk, walk (IOW,
"transfer via sneaker net") that alias to another Mac on the network,
and open *the original file* from that other Mac.  (I could even move
the file to another folder on the original Mac, but that didn't mean
much, because those old file systems were entirely flat (directories and
folders were an illusion maintained by the Finder).)

Permissions?  We don't need no stinkin' permissions!  ;-)

> > another and it just runs.  As it should.  Things should be simple.
> 
> +1

I like simple, portable things, too.  But this kind of simplicity
(applications looking in known locations for certain files) and this
kind of portability (allowing users to move those files) are at oods.
And that's before we consider security.

Also, [almost] by definition, Python virtual environments really blur
the lines between user, system, public, private, programs, and data.
-- 
https://mail.python.org/mailman/listinfo/python-list