Main recode/rework thread

[Tim Cas]

This is the main thread to discuss reorganizing the TinyPy project (recode or not).

[Tim Cas]

Well, to begin, I think we should decide whether TinyPy should be recoded from scratch or not; furthermore, exactly how much of "big" Python to implement, if and where to extend it (say, tail call optimization).

Also one important question is, should bytecode try to remain compatiable with that of CPython? I think not (I'll give reasons later if anyone disagrees), but I want to hear your ideas.

[Taillon]

Personally, I'm not interested in total recoding, as I don't have time
nor understanding to do so, now.
What's the problem with the current code, exactly, other than bugs and
some design flaws (as any software may have)?
Maybe we can list up all known issues, first.
Doe example, issue 27 test fails on TinyPy1.1, for example.

As for the implementation, I'd prefer slightly more compatibility (not
at the byte code level) in a few areas to reduce the work required for
porting some python codes (like python 2.c print statement, although I
don't like it much).

On Feb 17, 9:07 am, Tim Cas <darkuran...@gmail.com> wrote:
> Well, to begin, I think we should decide whether TinyPy should be recoded
> from scratch or not; furthermore, exactly how much of "big" Python to
> implement, if and where to extend it (say, tail call optimization).
>
> Also one important question is, should bytecode try to remain compatiable
> with that of CPython? I think not (I'll give reasons later if anyone
> disagrees), but I want to hear your ideas.
>

[Andy O'Meara]

Hi Tim and all,

We're actually almost finished with a major recode of tinypy that I've been waiting to share with the group.  For some background and further info:

http://groups.google.com/group/tinypy/browse_thread/thread/02426e115e6026aa/385a6fc608569eef?#385a6fc608569eef

So, we've actually been working on this stuff considerably over the last couple months, and the only piece left until we've reached the first major milestone (code cleanup, compartmentalization, API formalization, and project cleanup) is making some decisions about a hybrid gc system (ref counting vs pure gc).  As it stands, we have things looking pretty sexy and clean, with the one exception that the gc load can start to be wasteful/scary under normal conditions of a embedded interpreter running for long periods of time in a real-time application (e.g. high performance game). For example, in a typical embedded application ("embedded" as in embedding tp in an app, not as in an app running on "small"/embedded hardware), the interpreter could persist and be run incrementally for hundreds of scripts while other more critical real-time load is present, so if every non-trivial allocated object (e.g. a runtime string) passed into tp from the outside world has to be put into the gc tracker, the gc start to get gc load can start to get ugly.  We've been considering strategies that will detect objects that quickly become unreferenced (rather than just letting them be throwin into the gc pool for general collection).  Am I explaining this well?  It's hard to describe without typing a book.

In any case, I wanted to wait a little longer before announcing all this, but I didn't want folks to dive into a rework w/o knowing about our progress.  I've presented our work to a couple companies, including to Enthought based here in Austin, and we've gotten a LOT of interest.  If there's real interest here, I can go into where we're at and posting an archive of what we have.  If I got the blessing from folks here, I could also just commit it as a branch.

Andy O'Meara

SoundSpectrum Inc

--
You received this message because you are subscribed to the Google Groups "tinypy" group.
To post to this group, send email to tin...@googlegroups.com.
To unsubscribe from this group, send email to tinypy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tinypy?hl=en.

[Phil Hassey]

I'd certainly like to learn more about this! -Phil --- On Thu, 2/17/11, Andy O'Meara <and...@gmail.com> wrote:

[Dean Hall]

Andy, are you going to pycon in March?

!!Dean

[Tim Cas]

Hmm, interesting...

And regarding the GC, have a look at generational GC's - those take advantage of the fact that most recently allocated objects are usually the most short-lived ones.

What kind of a GC is it though, if I may ask?

On 17 February 2011 19:55, Dean Hall <dwha...@gmail.com> wrote:

Andy, are you going to pycon in March?

!!Dean

On Feb 17, 2011, at 09:12 , Andy O'Meara wrote:

Hi Tim and all,

We're actually almost finished with a major recode of tinypy that I've been waiting to share with the group.  For some background and further info:

http://groups.google.com/group/tinypy/browse_thread/thread/02426e115e6026aa/385a6fc608569eef?#385a6fc608569eef

So, we've actually been working on this stuff considerably over the last couple months, and the only piece left until we've reached the first major milestone (code cleanup, compartmentalization, API formalization, and project cleanup) is making some decisions about a hybrid gc system (ref counting vs pure gc).  As it stands, we have things looking pretty sexy and clean, with the one exception that the gc load can start to be wasteful/scary under normal conditions of a embedded interpreter running for long periods of time in a real-time application (e.g. high performance game). For example, in a typical embedded application ("embedded" as in embedding tp in an app, not as in an app running on "small"/embedded hardware), the interpreter could persist and be run incrementally for hundreds of scripts while other more critical real-time load is present, so if every non-trivial allocated object (e.g. a runtime string) passed into tp from the outside world has to be put into the gc tracker, the gc start to get gc load can start to get ugly.  We've been considering strategies that will detect objects that quickly become unreferenced (rather than just letting them be throwin into the gc pool for general collection).  Am I explaining this well?  It's hard to describe without typing a book.

In any case, I wanted to wait a little longer before announcing all this, but I didn't want folks to dive into a rework w/o knowing about our progress.  I've presented our work to a couple companies, including to Enthought based here in Austin, and we've gotten a LOT of interest.  If there's real interest here, I can go into where we're at and posting an archive of what we have.  If I got the blessing from folks here, I could also just commit it as a branch.

Andy O'Meara
SoundSpectrum Inc





On Thu, Feb 17, 2011 at 8:07 AM, Tim Cas <darku...@gmail.com> wrote:
Well, to begin, I think we should decide whether TinyPy should be recoded from scratch or not; furthermore, exactly how much of "big" Python to implement, if and where to extend it (say, tail call optimization).

Also one important question is, should bytecode try to remain compatiable with that of CPython? I think not (I'll give reasons later if anyone disagrees), but I want to hear your ideas.


On 15 February 2011 22:08, Tim Cas <darku...@gmail.com> wrote:
This is the main thread to discuss reorganizing the TinyPy project (recode or not).


--
You received this message because you are subscribed to the Google Groups "tinypy" group.
To post to this group, send email to tin...@googlegroups.com.
To unsubscribe from this group, send email to tinypy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tinypy?hl=en.


--
You received this message because you are subscribed to the Google Groups "tinypy" group.
To post to this group, send email to tin...@googlegroups.com.
To unsubscribe from this group, send email to tinypy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tinypy?hl=en.

[Andy O'Meara]

On Thu, Feb 17, 2011 at 12:55 PM, Dean Hall <dwha...@gmail.com> wrote:

Andy, are you going to pycon in March?

 

Ugh, I bought tickets but had to cancel a few days ago due to just being overloaded and other stuff going on, sigh! I had hopes to have the gc hybrid done by pycon so that I could give away archives to tinypy and other ppl who were interested, but the gate closed on being able to present.  By next year I want to present our revs to tinypy, and maybe before then folks here will become excited about what we've done.  Who knows, maybe this time next year, the lot of us will be sitting on something that's as good, clean, and thread-unrestricted as lua (that's our goal here at SoundSpectrum anyway).  We're just losing our bloody shirts at how lousy CPython is when it comes to embedded python in a modern, real-time. multi-threaded desktop app like what we ship.

I'm really really excited about the API insulation, reorganization, and modularization we've done.  The theme is a professional package any commercial company would expect to see when dropping in a complete-solution embedded interpreter: self-documenting APIs, helpful debug mode checking, a separation of public vs private code, Xcode and MS Visual Studio demo projects, and an expansion of built-in modules.  One exciting add-on has been the abstraction of the file system in tinypy.  This allows an embedder to insert their own file system API (at the C/C++ level), useful for a variety of purposes.

We had to take a few week hiatus from this tp work for other priorities, but all this chit chat is getting me excited again! 

On Thu, Feb 17, 2011 at 12:55 PM, Dean Hall <dwha...@gmail.com> wrote:

Andy, are you going to pycon in March?

!!Dean

On Feb 17, 2011, at 09:12 , Andy O'Meara wrote:

Hi Tim and all,

We're actually almost finished with a major recode of tinypy that I've been waiting to share with the group.  For some background and further info:

http://groups.google.com/group/tinypy/browse_thread/thread/02426e115e6026aa/385a6fc608569eef?#385a6fc608569eef

So, we've actually been working on this stuff considerably over the last couple months, and the only piece left until we've reached the first major milestone (code cleanup, compartmentalization, API formalization, and project cleanup) is making some decisions about a hybrid gc system (ref counting vs pure gc).  As it stands, we have things looking pretty sexy and clean, with the one exception that the gc load can start to be wasteful/scary under normal conditions of a embedded interpreter running for long periods of time in a real-time application (e.g. high performance game). For example, in a typical embedded application ("embedded" as in embedding tp in an app, not as in an app running on "small"/embedded hardware), the interpreter could persist and be run incrementally for hundreds of scripts while other more critical real-time load is present, so if every non-trivial allocated object (e.g. a runtime string) passed into tp from the outside world has to be put into the gc tracker, the gc start to get gc load can start to get ugly.  We've been considering strategies that will detect objects that quickly become unreferenced (rather than just letting them be throwin into the gc pool for general collection).  Am I explaining this well?  It's hard to describe without typing a book.

In any case, I wanted to wait a little longer before announcing all this, but I didn't want folks to dive into a rework w/o knowing about our progress.  I've presented our work to a couple companies, including to Enthought based here in Austin, and we've gotten a LOT of interest.  If there's real interest here, I can go into where we're at and posting an archive of what we have.  If I got the blessing from folks here, I could also just commit it as a branch.

Andy O'Meara
SoundSpectrum Inc





On Thu, Feb 17, 2011 at 8:07 AM, Tim Cas <darku...@gmail.com> wrote:
Well, to begin, I think we should decide whether TinyPy should be recoded from scratch or not; furthermore, exactly how much of "big" Python to implement, if and where to extend it (say, tail call optimization).

Also one important question is, should bytecode try to remain compatiable with that of CPython? I think not (I'll give reasons later if anyone disagrees), but I want to hear your ideas.


On 15 February 2011 22:08, Tim Cas <darku...@gmail.com> wrote:
This is the main thread to discuss reorganizing the TinyPy project (recode or not).


--
You received this message because you are subscribed to the Google Groups "tinypy" group.
To post to this group, send email to tin...@googlegroups.com.
To unsubscribe from this group, send email to tinypy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tinypy?hl=en.


--
You received this message because you are subscribed to the Google Groups "tinypy" group.
To post to this group, send email to tin...@googlegroups.com.
To unsubscribe from this group, send email to tinypy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tinypy?hl=en.

[Taillon]

I am excited to hear that , Andy !

So, TinyPy+TCC package can be not just a toy language playing kit but
a small foot print industrial strength reliable script+c package.
If a bit of Cython feature is integrated so that C data/struct /
function/dll can be easily used from Tinypy, it would be magical.
(And that frame saving and loading feature to shorten startup time of
some apps).

What is the target platform? Does it include ARM and OS other than
*nix (including Mac) and Win?

Can we take a look at the code?

[Andy O'Meara]

Well, thus far, we've only just identified the need I described.  To be clear, the usage case is that you have a real-time app with an embedded tp interpreter running scripts over the app's lifetime.  The app is something comparable to a game in that it could be running for several hours with scripts constantly being run on the same interpreter instance (not necessarily high load scripts, but scripts that involve the usual instantiation of a few hundred objects each time they're run, only a dozen of which remain referenced once the script is complete).  

I'm still getting my arms around the problem (I don't have much gc experience), but I'd love to work with folks here that have a lot of gc theory and implementation experience to help work towards a better gc subsystem.  

Over the years I've been discouraged by folks who say they're interested in contributing but don't in the end, so that's why we've taken this project on privately and quietly thus far.  I've spent hundreds of hours going back and forth with certain people in the CPython dev community that frankly were just unwilling to listen to the needs and priorities of commercial app developers.  And frankly we're done with them, and they can have their butt-slow, lumbering, and thread-restrictive CPython.  They can also have their GIL while we do with Python what should have been done years ago (and why Lua is used over Python today by commercial developers that ship software that everyday people pay for--like us).

I don't mean to rant or get on a soapbox -- just trying to paint some background.  :)

Andy

[Andy O'Meara]

The way we have it, it's far from a toy now.  We've cleanup all the bootstrap and multi #include stuff so that we now have Visual Studio and Xcode hello world projects that contain an interpreter instance that persists (and executes newly formed fragments made by the app, etc).  This is why the gc performance discussion from my previous post is relevant.

For folks here that are seriously interested in this (to actually contribute than just endlessly discuss), please read though the earlier thread I linked to:

http://groups.google.com/group/tinypy/browse_thread/thread/02426e115e6026aa/385a6fc608569eef?#385a6fc608569eef

This will help provide some context so that my poor little hands don't die from a typing overdose.

As for target platforms, it's the ones that matter, in the context of commercial development.  Our current rev is intended to support any compiler that supports C99 and uses either Darwin (OS X), posix, or Win32 -- which is basically everything that matters.

[Tim Cas]

Hm, I guess firstly, I should say I'm sorry for making you bring up this project earlier than expected.

Regarding TinyPy, I have 2 questions (for now ^^)

1) Will it be written in C or C++?
2) Will it compile with MinGW on Windows (as opposed to -- or along with -- MSVC)

I ask this because I *personally* much prefer C over C++, and I also prefer the GCC toolchain on Windows over the MS toolchain.

So yes, this question is for me! =)

[Taillon]

Thanks for the answer, Andy.

I saw the thread you linked and I know a bit what you felt with python-
dev guys, as I was in a team that ported Python2.3 to WinCE (for PSA
and smartphones).

Using multiple VM (spawned by mother-monitoring VM embedded in a web
server) is something I was hoping to do once TinyPy become really
stable/usable.
So, the child VM may not have very long life span, but the mother VM
should be able to stay healthy for long time.
I would use this to implement a communication-collaboration tool for
the company I'm working now.
I could have used Apache+Python or Perl, which I have done before, but
I want something lighter than that and easily modifiable than that.

As for contributing, I was working as a programmer about 25 years ago
with tiny amount of memory and CPU power. So, I'm pretty keen on
making things small and fast.
Although I can't be a help for the GC issue, I'm usually good at
making things easy and attractive for end users and inexperienced
people.
(I did lots of end user support and making installation kit for web
apps written by me and others)
I did adaptation of some Python modules to WinCE, and emulating
certain things missing on that platform, etc, in the porting project,
too.

As I want TCC support, I can take care of that, at least, In addition
to testing and any other thing I can do with my ability and time.
Maybe I can write (or modify and adapt) CGI-app like tiny wiki, simple
forum as samples so that more people are interested.
(Web app developers and users are important segment for a script
language)

Other than GC issue, what is needed?
Is the build process still based on setup.py type of thing or with
make (other than MSVS project)?

If the code is available, I'll start checking out right away, as I
prefer to work with better code than spending time on older code and
then repeat the work again.

[Tim Cas]

Regarding the setup, CMake might not be a bad idea if you don't use distutils... Just an idea - I use it for my project (it's a game engine -- and that's why I want to use TinyPy, primarily) and even though it has its set of problems (but then, which software doesn't?), it's working out great =)

--

[Chris McCormick]

Hi Andy,

Your work sounds awesome. What license will it be available under when you
release it?

On Thu, Feb 17, 2011 at 02:19:40PM -0600, Andy O'Meara wrote:
> Over the years I've been discouraged by folks who say they're interested in
> contributing but don't in the end, so that's why we've taken this project on
> privately and quietly thus far. I've spent hundreds of hours going back and
> forth with certain people in the CPython dev community that frankly were
> just unwilling to listen to the needs and priorities of commercial app
> developers. And frankly we're done with them, and they can have their
> butt-slow, lumbering, and thread-restrictive CPython. They can also have
> their GIL while we do with Python what should have been done years ago (and
> why Lua is used over Python today by commercial developers that ship
> software that everyday people pay for--like us).

Thousands of people ship software every day that people pay for using CPython.
I am extremely grateful to the CPython devs for making such an awesome language
available as Free Software so that so many of us can benefit.

I look forward to seeing the source code and trying out your new iteration of
TinyPy, and I'm especially excited reading your comparisons to lua.

Cheers,

Chris.

-------------------
http://mccormick.cx

[Andy O'Meara]

1) Will it be written in C or C++?
2) Will it compile with MinGW on Windows (as opposed to -- or along with -- MSVC)

Over my years, I've come to respect and appreciate the basic built-in features of C++ (constructors/destructors, function overloading, honest use of public/protected keywords) but none of the hotshot stuff that typically adds confusion (templates, operator overloading, and multiple inheritance).  

So, to maintain moderate svn continuity with the current orignal codebase but yet get some of the niceties offered by C++, I went with a very simple class interface called tp_Interpreter that wraps the existing tp code inside it, safely away.  This doubles as the public API, so to get an interpreter up and running, you just need to create and hold an instance of tp_Interpreter wherever, and you're ready to rock.  I mentioned that I've abstracted the file system and did this by a class called tp_FileSys.  When you make a tp_Interpreter instance, you have to feed it ptr to a tp_FileSys instance.  The factory tp_FileSys class is implemented via posix, but the embedder can make his own tp_FileSys subclass and implement the entire file system with however they like.  For example, you could make your file system completely heap-resident.  The other thing you need in order to construct a tp_Interpreter instance is a tp_Console object.  As you can imagine, this handles all console i/o, so again you the embedder are free to make a tp_Console subclass and process console i/o as you like.  You should be starting to see a pattern, which is the mission for any commercial-caliber package: tp doesn't make any direct calls to *any* api (other than its handler objects, which can all be replaced with instances of user subclasses).

Other major encapsulation work that's been completed is the compilation process.  There's no more black magic with bootstrapping every interpreter instance with the ability to compile python code--this isn't optimal.  Instead, there's a comprehensive threadsafe global proc that compiles python source code into an output TPC buffer.

tp_result tp_compile( const tp_buf& inSrcBuf, const char* inDesc, tp_buf* outTPC, tp_Console* inConsole );

Internally, it's implemented via a simple multi-threaded dispatching system, where each thread has its own tp_Interpreter that's been bootstrapped to run as a compiler (the number of threads created is trivially changed and is set to be the number of cores on the system).  So now when an interpreter VM executes exec(), it now simply calls tp_compile() above (instead of calling back into itself).  You guys will see when you get a look at the code, but this approach has simplified how things work and made the footprint of a tp_Interpreter very small since it doesn't have to carry around its compilation code anymore.  I took a lot of care to make sure all the stuff can scream on a well-endowed, multi-core system.  In other words, if you had an 8 core system, you could be running 7 interpreters at the same time while occasional calls to tp_compile() (either from the running interpreters or from the user) won't have any impact on performance -- well, y'all get the idea.  :)

As for MinGW, we're talking plain-vanilla C99 and C++ code (and no templates or other packages) so this should compile under anything that can compile win32 (which would include mingw).  In fact, I've taken the liberty and basically no longer use the old way tp was being build.  Now, it's simply a set of files intended to be build via the the Xcode project file, MSVS project file, or makefile.  The "interpreter" app is now simply a page of source that makes a tp_Interpreter, feeds it a stock tp_FileSys and tp_Console object, and calls the tp_Interpreter instance method to execute the given pathname.

There's more cool stuff we've added, but I'd say it's best categorized as growing tinypy into:

(a) something a serious commercial developer will consider

(b) something a serious developer will consider contributing to (modules, performance, compiler, etc)

 

Excited yet?  :)

[Andy O'Meara]

Very cool!

Well, gents, I'll have to be honest and say I sense that we have a
pretty good, committed crew here. I think we're all here having this
discussion in the first place because we've sort of figured out ahead
of the curve that CPython just doesn't work well in today's world of
parallelization, multi-core systems, compartmentalization, and mobile
hardware.

You guys are motivating me to button my work up! Given the interested
and good will here, give me a week to button things up and do some
README stuff and I'll be able to present it (but w/o any gc changes I
raised earlier).

The build/setup process no longer uses any scripts whatsoever. Here's
what there is now:

- source+header files req'd for any project that uses tp.
- a ten line script that builds the 4 .tpc files form their
respective .py files (only needs to be run once obviously)
- an xcode and msvc project that contains all the src files, plus a
one page main.cpp:


int main( int argc, const char* argv[] ) {

if ( argc < 2 ) {
printf( " usage: tinypy file[.py|.tpc] arg0 arg1 ...\n\n" );
return -1;
}

tp_result result = tp_NoErr;
tp_buf exePath, exeFile;
tp_FileSys fileSys;

// Set exePath and exeFile
{
fileSys.GetParentDir( argv[ 0 ], &exePath );
exePath.AppendChar( NATIVE_PATH_SEP_CHAR );

tp_buf cwd;

// Absolute or relative?
if ( argv[ 1 ][ 0 ] == NATIVE_PATH_SEP_CHAR )
exeFile.Assign( argv[ 1 ] );
else {
fileSys.GetCWD( &exeFile );
exeFile.AppendVA( "%c%s", NATIVE_PATH_SEP_CHAR, argv[ 1 ] );
}
}


// Load the compiler support data
{
tp_CompilerROM ROM;

tp_buf path;
path.AppendVA( "%s%ctp_support", exePath.CStr(),
NATIVE_PATH_SEP_CHAR );

result = ROM.LoadFromDir( path.CStr() );
tp_assert( result == tp_NoErr );

// Startup tinypy, yay!!
result = tp_startup( ROM );
tp_assert( result == tp_NoErr );
}


if ( result == tp_NoErr ) {
tp_Interpreter interp;
tp_Console console;

interp.SetConsole( &console );
interp.SetFileSys( &fileSys );

result = interp.Initialize( argc - 2, &argv[ 2 ] );
tp_assert( result == tp_NoErr );

// This technically isn't necesssary to run our file
interp.AddPath( exePath.CStr(), tp_PathIsNative );

interp.ExecuteFile( exeFile.CStr() );

interp.Finalize();
}


// Shutdown tinypy
tp_shutdown();

return 0;

[Andy O'Meara]

I don't want to make any promises yet, but I anticipate it will be the MIT license, in continuation and in the spirit of Phil's original work.  That said, there's a couple design principles that we probably won't be willing to compromise on, but those principles benefit the project than subtract from it.  For example, modules are not permitted to have any static/global variables since that would take away unrestricted multi-threaded support.  

I just don't want to be in a situation where SoundSpectrum has to quibble with people or convince anyone of anything.  I know that may sound like "our way or the highway", but I'm just trying to make the point that we unfortunately don't have the resources to do absolutely everything.  For example, I made the decision to remove the setup.py script stuff that jams all the .c files into one massive file for a list of reasons.  The Xcode/MSVS projects we now have instead are an improved and more straight-forward approach that I would prefer not to debate with people if their only basis is "that's not how we did it before" or to satisfy people who feel that it has to build from a clever script.  Not trying to be bossy with all of this, just trying to be honest and say that we don't have the resources to engage in lengthy debate unless it's with people who are putting in real contributions into this project.

On that note, if there are one or two people who really take to this project, SoundSpectrum will likely be willing to put them on payroll (depending on the kind of work planned).  

[Phil Hassey]

Just a couple thoughts: - MIT license is quite important for tinypy to be useful.  Other licenses are too restrictive or too obscure to be generally useful. - I think we'll all be quite interested to take a look at what you've got put together. - "For example, modules are not permitted to have any static/global variables ..." What does that mean?  Best I understand a modules contents is all global variables? - "I just don't want to be in a situation where SoundSpectrum has to quibble with people or convince anyone of anything."  I totally understand.  I think the people here will need to see what SS has created, and if it matches what we all want as tinypy then it could become the new edition of tinypy.  If it doesn't really match what we want, then it'll become it's own python variant.  Either way a situation where SS was at odds with anyone is to be avoided. Cheers! -Phil

--- On Fri, 2/18/11, Andy O'Meara <and...@gmail.com> wrote:

From: Andy O'Meara <and...@gmail.com> Subject: Re: [tinypy] Re: Main recode/rework thread To: tin...@googlegroups.com

[Andy O'Meara]

> - MIT license is quite important for tinypy to be useful.  Other licenses are too restrictive or too obscure to be generally useful.

Totally agree.

> - "For example, modules are not permitted to have any static/global variables ..."
> What does that mean?  Best I understand a modules contents is all global variables?

I meant on the C/C++ side. The only rule is that any C-side storage
has to be made inside the module object (vs a C static/global). This
way, an interpreter object that uses module X will be completely
independent from another interpreter instance also using module X,
preserving interpreter independence (thus permitting concurrent
interpeter execution). To be technically accurate, global C-side data
structures *can* exist, they just has to be read-only (e.g. a lookup
table). Hopefully I'm explaining this ok.

> - "I just don't want to be in a situation where SoundSpectrum has to quibble with people or convince anyone of anything." 
> I totally understand.  I think the people here will need to see what SS has created, and if it matches what we all want as tinypy then it could become the new edition of tinypy.  If it doesn't really match what we want, then it'll become it's own python variant.  Either way a situation where SS was at odds with anyone is to be avoided.

Perfectly said. :)

> For more options, visit this group athttp://groups.google.com/group/tinypy?hl=en.

[Tim Cas]

> - MIT license is quite important for tinypy to be useful.  Other licenses are too restrictive or too obscure to be generally useful.

MIT or (possibly 2-clause) BSD -- but given that TinyPy was MIT (I believe?), that should be the license of the "new" TinyPy.

One of the reasons I don't like C++ is non-standarized name mangling and object storage in memory -- this means that I can't, for example, use a MSVC-compiled TinyPy with MinGW. Furthermore, bindings become a more complicated.

That said, I'm still looking forward to a decent smallish Python implementation, I just wish it was 100% C.
I suppose I'll just have to make C bindings out of the C++ bindings then...

[Andy O'Meara]

> One of the reasons I don't like C++ is non-standarized name mangling and
> object storage in memory -- this means that I can't, for example, use a
> MSVC-compiled TinyPy with MinGW. Furthermore, bindings become a more
> complicated.
>
>

why wouldn't you just compile tinypy under mingw along with everything
else?

[Taillon]

Hi Andy,

Thanks for the info and hard work.

Using C++ would be a problem for my desire to support TCC.
But it's your baby and I will think about what I may be able to do
when I see the code (rewriting C++ portion in C, trying LLVM, etc)
.
Other than that, it sounds terrific and I'm waiting, impatiently. :)

Let us know if there is anything we can help.

[Tim Cas]

Taillon, if you're planning to rewrite the C++ portion in C, count me in.

[Andy O'Meara]

Well, since I'm only using constructors/destructors, function name overloading, and class semantics only for the purposes of encapsulation, perhaps it wouldn't be that bad to either find or make a core C++ to standard C preprocessor.  There's probably a bunch of stuff out there already for vanilla C++.   I'm not totally opposed to just C, it's just that basic constructor/destructor and function overloading makes code SO much nicer to read and write imho. My head would explode if, on top of trying to do a quality, industrial-strength refactor, I had to worry about initializing some structure or remember to release an allocation.

[Taillon]

Thank you for your support, Tim, and thank you for the additional
info, Andy.

We'll see the code and think more about what we can do for making pure
C (or compatible with C) branch(?), eventually.

I'm thinking options like;
* Hand rewriting
* Using LLVM + manual adjustment)
* Using Cfront etc to convert C++ to C.
* (Making? and) Using TinyPy C-API to replace what C++ is doing (as
much as possible).

Since I would like to make even VM and frames into tp_object (using
tp_data?), I guess I may try to do it by the last option (probably
combined with hand rewriting some part), as long as it doesn't cause
any secondary problem (like speed or stability issue). This way, we
can hopefully control VMs (and compiler thread) from script side, as
well.
But I'd put my effort to help Andy get going with the way he is doing/
comfortable, first, to have reliable packages released.
Once it's done and more people get interested in, I'm sure there would
be even more demand/help for C version, as well.

Anyway, let's see the code and we'll find a way.

I just hope someone who knows well about different GCs and how to
implement them comes in to help us.

[Andy O'Meara]

Yay, I'm so glad and motivated that we seem to have cadre of ppl that
are all interested in making something great!!

All we need now is a token CPython guy here to naysay everything.
Too harsh?? :)

[Tim Cas]

Can't wait to see this done! *jumps around in excitement*

Anyways, any ETA before the software is *somewhat* usable?

[illume]

Hi,

I'm looking forward to your release too.

> >> *
> >> http://groups.google.com/group/tinypy/browse_thread/thread/02426e115e6026aa/385a6fc608569eef?#385a6fc608569eef
> >> *

[Andy O'Meara]

I've made a new thread with our "tinypy++" preview:

http://groups.google.com/group/tinypy/browse_thread/thread/44a0ffbf5da1c3b

> > On Thu, Feb 17, 2011 at 4:04 PM, Tim Cas <darkuran...@gmail.com> wrote:
>
> > > Hm, I guess firstly, I should say I'm sorry for making you bring up this
> > > project earlier than expected.
>
> > > Regarding TinyPy, I have 2 questions (for now ^^)
>
> > > 1) Will it be written in C or C++?
> > > 2) Will it compile with MinGW on Windows (as opposed to -- or along with --
> > > MSVC)
>
> > > I ask this because I *personally* much prefer C over C++, and I also prefer
> > > the GCC toolchain on Windows over the MS toolchain.
>
> > > So yes, this question is for me! =)
>
> > > On 17 February 2011 21:38, Andy O'Meara <and...@gmail.com> wrote:
>
> > >> The way we have it, it's far from a toy now.  We've cleanup all the
> > >> bootstrap and multi #include stuff so that we now have Visual Studio and
> > >> Xcode hello world projects that contain an interpreter instance that
> > >> persists (and executes newly formed fragments made by the app, etc).  This
> > >> is why the gc performance discussion from my previous post is relevant.
>
> > >> For folks here that are seriously interested in this (to actually
> > >> contribute than just endlessly discuss), please read though the earlier
> > >> thread I linked to:
>
> > >> *

> > >>http://groups.google.com/group/tinypy/browse_thread/thread/02426e115e...

[Oyster]

I hope ctypes can be realised