of choice for
Android and IOS.
Sadly, I didn't have the time for such a project.
Now, it appears PythonForAndroid has morphed into QPython or something
On 19 March 2015 at 18:26, Jeff Senn s...@maya.com mailto:s...@maya.com
wrote:
I have a patch that switches out the python
Hi Michael -
I'm unclear after reading your message whether you are primarily interested in
OS X or iOS.
If the latter ( or you are interested in even more cross-platform-ness) you
might want to know about
Kivy ( http://kivy.org ). Of course (as you are probably aware) you have to
take a
--
If you take a close look at it, there is no definition for __arm__ or
__arm32__. So I have to manually add that definition to the header file.
Now the problem is solved. I want to thank everyone who helped!
Bin
On Thu, Jul 24, 2014 at 7:37 PM, Jeff Senn s...@maya.com
Make sure that your compile options are all correct and that that branch of
code is actually being compiled.
Hint: try (temporarily) putting a syntax error or unresolvable link error into
the code in the branch of the #ifdef
you think is being compiled and then “make clean; make” and see if
On Jul 24, 2014, at 2:47 PM, Bin Huang bin.art...@gmail.com wrote:
Hi Anselm,
The reason I used Stackless 2.6.5 is because my project needs to support the
execution of a subset of the Python 2.6 bytecodes.
But I did try 2.7.8 as you suggested. Interestingly, I had the same problem
Kristján-
Did you ever make any progress on the Kivy port?
On Nov 22, 2013, at 9:38 AM, Kristján Valur Jónsson krist...@ccpgames.com
wrote:
-Original Message-
From: stackless-boun...@stackless.com [mailto:stackless-
boun...@stackless.com] On Behalf Of Christian Tismer
Sent: 22.
+a million
I’ve been meaning to find time to look into that…please post if/when you make
progress!!
(Although the kivy framework is very interesting, merely having a maintainable,
embeddable,
and stackless python that is cross platform and supports Android (and iOS) is a
big deal)
-Jas
On
That was not it -- in fact the ARM port was still fine (though I do use a
slightly different toolchain for that) -- just the 32 bit version of i386 for
OS-X was misbehaving. I suspect it had to do with some inlining or
optimization that clang was doing (differently than a previous version).
I
On Sep 19, 2013, at 12:52 PM, Bin Huang bin.art...@gmail.com wrote:
Thanks, Rich. What I did not fully understand before was that the tasklets
are all part of the one thread.
Hm. Tasklets are not precisely all part of one thread -- however (see below)
they might as well be for
purposes of
Bin Huang:
Did I miss it? Did you verify it is not a 32-bit vs 64-bit compile issue
(as Richard obliquely asked)?
On May 8, 2013, at 8:39 AM, Christian Tismer tis...@stackless.com wrote:
Hey guys,
On 08.05.13 04:31, Bin Huang wrote:
On Tue, May 7, 2013 at 6:54 PM, Richard Tew
On Sep 9, 2011, at 2:37 PM, Kristján Valur Jónsson wrote:
Hm, you are probably right. Maybe Im just fussing about. I'll have to go
and investigate some more.
Btw, all of this comes from a desire to hand off jobs to tasklets on other
threads. What I am aiming to add is a way to figure
. There was the exact same problem
with static globals in greenlet, where slight changes in code would make
corruptions go away.
On Aug 18, 2011 5:20 PM, Jeff Senn s...@maya.com wrote:
Anselm - can you have a look and see what you think of Alexey's version?
Compare with your earlier proposal? What
Anselm - can you have a look and see what you think of Alexey's version?
Compare with your earlier proposal? What is you current best version for me to
test on OS-X
(preferably w/o the darwin specific compile option which I can't tell if you
thought was necessary or not...)
FWIW: My problem
On Jul 13, 2011, at 6:42 PM, Richard Tew wrote:
On Thu, Jul 14, 2011 at 6:14 AM, Anselm Kruis
a.kr...@science-computing.de wrote:
3. Using the clobber mechanism is a mixed blessing. On the one hand the
compiler knows what to preserve. On the other hand, we have no guarantee, at
which
As I'm responsible for that patch -- I'll simply say that IIRC no one was sure
that it was working at all on 64-bit
Linux at the time...and I didn't have a 64 bit linux system to test (there's
probably a discussion on the list, or I can dig up email if
anyone cares...)
In any case, I'd be happy
So what is the plan for a source repository for stackless? (now that python
proper is moving/has moved to hg.python.org)
K, you mentioned Nagare is there one in the Nagare repos somewhere? Is
that going to be official? Should this:
http://zope.stackless.com/svn/sdocument_view get
On Feb 10, 2011, at 9:43 AM, Christian Tismer wrote:
On 2/10/11 4:02 AM, Jeff Senn wrote:
On Feb 9, 2011, at 9:27 PM, Christian Tismer wrote:
And I'm wondering about the connection to openWRT ??? It is a quite
different theme and I read a lot about it for my Buffalo router.
What
On Feb 9, 2011, at 9:27 PM, Christian Tismer wrote:
And I'm wondering about the connection to openWRT ??? It is a quite
different theme and I read a lot about it for my Buffalo router.
What is the relation to Stackless?
Although all this router stuff is great, I have very different thought
On Jan 13, 2011, at 10:15 PM, Richard Tew wrote:
On Fri, Jan 14, 2011 at 1:59 AM, Andrew Francis andrewfr_...@yahoo.com
wrote:
Richard I am researching how greenlets work. A part of this is actually
looking at the code with a debugger. However I do not see a problem with
also asking
On Dec 7, 2010, at 10:08 PM, Richard Tew wrote:
On Mon, Dec 6, 2010 at 6:55 AM, Daniel Norberg daniel.norb...@gmail.com
wrote:
I've discovered a possible bug in Stackless 2.6 on Mac OS X Snow Leopard.
Running the following script using a x86_64 stackless on Mac OS X Snow
Leopard produces
wrote:
On Wed, Dec 8, 2010 at 10:28 PM, Jeff Senn s...@maya.com wrote:
However, this does NOT occur in the branch of Stackless 2.7 that I have
around,
so my interest in pursuing this is pretty low... (if someone has an idea
where
to look specifically I could devote a bit of time
it meeting much
enthusiasm.
FWIW - sounds good to me!
K
-Original Message-
From: stackless-boun...@stackless.com [mailto:stackless-
boun...@stackless.com] On Behalf Of Jeff Senn
Sent: 5. júlí 2010 02:46
To: The Stackless Python Mailing List
Subject: Re: [Stackless] stackess
] On Behalf Of Jeff Senn
Sent: 1. júlí 2010 18:08
To: The Stackless Python Mailing List
Subject: Re: [Stackless] stackess for 2.7
On Jul 1, 2010, at 12:08 PM, Jeff Senn wrote:
Speaking of 64bit... are you compiling a 64bit version? I am having
some trouble...
In particular test_cpickle
to ignore TaskletExits...
We best leave this alone and worry about it later.
K
-Original Message-
From: stackless-boun...@stackless.com [mailto:stackless-
boun...@stackless.com] On Behalf Of Jeff Senn
Sent: 25. júní 2010 12:43
To: The Stackless Python Mailing List
Subject: Re
: stackless-boun...@stackless.com [mailto:stackless-
boun...@stackless.com] On Behalf Of Jeff Senn
Sent: 24. júní 2010 16:13
To: The Stackless Python Mailing List
Subject: Re: [Stackless] stackess for 2.7
Progress - it's now building, but I do see regular python test fails
(compared to stock 2.7
with the slot wrapper object size (for int.__add__) being 44
bytes instead of 40.
(This might be correct for stackless -- it appears this test is commented out
in release26_maint)
and I haven't check the tk stuff yet at all...
On Jun 24, 2010, at 10:18 AM, Jeff Senn wrote:
Good so far
?) I'm willing to help out...
On Jun 23, 2010, at 6:27 PM, Richard Tew wrote:
On Thu, Jun 24, 2010 at 3:34 AM, Jeff Senn s...@maya.com wrote:
Now that Python 2.7 is imminent... is there a plan to merge in for Stackless
2.7?
In due course.
To quote an email Kristjan sent:
I have updated
I had this problem too (embedding Python in a completely different way and on
OS/X),
that is: a crash in GC during Py_Finalize. I spent just a bit of time looking
but didn't resolve much -- my (not very satisfying) solution was *not* to call
Py_Finalize since my program was exiting anyway.
I
*sigh*
I'm really hoping that the world hasn't gotten to the point
where we feel that software needs to be updated frequently to be
trustworthy or useful.
[I think I will (almost) avoid a serious bout of contentiousness by
skipping a statement here about the relative merits of
Christian-
I assume what you mean by this is that you would require Psyco (or part of it)
to re-write
tasklet code in such a way to allow tasklets to exit/enter at many points.
While that
might be interesting (and perform well) for scenarios where there are
relatively few
entry/exit points
On Nov 24, 2009, at 3:43 PM, Kristján Valur Jónsson wrote:
Yes, what you describe sounds like a fair normal scenario and is precisely
what the cstack's serial member is supposed to make work.
Now, in the first main, that main tasklet returns. You then enter a second
main and when this
[mailto:stackless-
boun...@stackless.com] On Behalf Of Kristján Valur Jónsson
Sent: 25. nóvember 2009 15:18
To: Jeff Senn
Cc: stackless list
Subject: Re: [Stackless] st.serial -- st.serial_last_jump patch
Thanks, Jeff.
I also am able to reproduce your problem, using test_outside().
I expect to crack
...@stackless.com] On Behalf Of Jeff Senn
Sent: 24. nóvember 2009 14:39
To: stackless list
Subject: [Stackless] st.serial -- st.serial_last_jump patch
Kristjan (or anyone else if you've looked at it)-
RE: Your serial_last_jump patch...
In my attempt to go to 2.6.4 I included your patch
This whole issue (the side-by-side install of Stackless and normal
Python)
is more complicated than it seems (unless I really want a 150MB copy of
something that is 99% the same and then remember which one is which, and
which packages are installed where) -- and since Stackless is meant
as a
I think if you do a normal (configure) build, it leaves some .o files
around in a place that confuses the build-installer build...
(Something like they are detected in the Parser dir so are not re-built
into the build dir I forget the details...)
rm Parser/*.o (or make dist-clean) will fix
I didn't check uber-carefully, but it seemed like the former -
otherwise I would have suggested patching it. :-)
IIRC it had to do with making the cute little folder icon resource
that makes the disk image folder look nice -- and I don't see
how it could be stackless related (However, I did not
mistakes.) This is on one of the new
unibody Macbooks. Am I doing something silly?
Best,
Kevin
On Fri, Jun 19, 2009 at 6:52 PM, Jeff Senn s...@maya.com wrote:
I didn't check uber-carefully, but it seemed like the former -
otherwise I would have suggested patching it. :-)
IIRC it had to do
list archives
just tell me to RTFM :)
Best regards
Mads
Mads Darø Kristensen wrote:
Hi Jeff.
Jeff Senn wrote:
Hm. Do you mean thread or process? Because of the GIL you
cannot use
threads to overlap python
execution within one interpreter (this has been discussed at great
length here many times
On Mar 19, 2009, at 5:49 AM, Mads Darø Kristensen wrote:
I have built an execution environment using stackless, and in it I
spawn a thread per CPU core so as to utilize the CPU properly. When
I then schedule tasklets I alternate between inserting the tasklet
from the different threads.
Hm - I'm probably responsible for the #ifdef -- though perhaps not
the whole string of reasoning that led up to it. I seem to
recall it has something to do with gcc on x86 and what version of
gcc you are using... (possibly searching the list archive would
provide more details) basically it just
To expand further: I believe several of the Linux python binary package
managers (Ubuntu, Fedora...) have taken to defaulting to the
4-byte unicode mode (IMHO, a dubious decision...)
Also it used to be that easy_install(eggs) would not correctly
make sure that the unicode compile options
On Jan 16, 2009, at 1:03 PM, Denis Bilenko wrote:
Interesting!
I spent some time with eventlet, a networking library built on top of
greenlet (for CPython).
It has the exact same goals as you stated below and aims to provide
the same set of services.
Here's an example that can get you feel
On Nov 19, 2008, at 1:01 PM, Larry Dickson wrote:
Is there a non-object-oriented flavor of Stackless Python? I've run
into this sort of thing before. OO techniques seem to require
extreme centralization, which kills fast, makes safe impossible
in the real world, and I'm not even clear on
I've been vaguely watching this discussion -- and I think there might
be a bit
of a communication mismatch pardon me if I'm wrong -- I'm probably
not paying enough attention...but
Stackless was not really designed to be the OS kernel layer to a
generic
On Sep 26, 2008, at 9:50 AM, David Naylor wrote:
My atomic is based on .set_atomic, and there should not be any
explicit
passing of control. I compensated for it [the apparent bug?] by
forcing a
reschedule until the correct tasklet came about...
Unfortunately my code that generates
For the record: I, too, am using setatomic (since I have a preemptive
stackless
tasklet scheduler -- and the scheduler itself is a tasklet and hence
needs
some control over preemption).
Also the stackless module (although it is a built in) should be
conducive to
runtime patching. E.g.
On Jul 15, 2008, at 8:55 AM, Richard Tew wrote:
On Mon, Jul 14, 2008 at 11:03 PM, Jeff Senn [EMAIL PROTECTED] wrote:
This looks like a general problem with asyncore... and not something
you are likely to have done in the port -- possibly poll() acts a
little differently on OS-X ... I'd have
47 matches
Mail list logo
