[ANN] Shed Skin 0.9
Hi all, I have just released version 0.9 of Shed Skin, a (restricted-)Python to C++ compiler. Please see my blog for the full announcement: http://shed-skin.blogspot.com The Shed Skin homepage is located here: http://shedskin.googlecode.com Thanks! Mark Dufour. -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
[ANN] Shed Skin 0.8
Hi all, I have just released version 0.8 of Shed Skin, an experimental (restricted-)Python-to-C++ compiler. Please see my blog for the full announcement: http://shed-skin.blogspot.com The Shed Skin homepage can be found here: http://shedskin.googlecode.com Thanks, Mark Dufour -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
[ANN] Shed Skin 0.7.1
hi all, I have just released Shed Skin 0.7.1, an optimizing (restricted!) Python-to-C++ compiler. It comes with some important extension module fixes, optimizations for several builtins (zip, min, max, map, filter, reduce, pow), a warning for non-uniform tuples of length > 2 and some minor fixes and internal cleanups. There are also two nice new examples (a quantum monte carlo simulator and an rsync implementation), bringing the count to 54 example programs, for a total of around 15,000 lines of code (as measured by sloccount). Please see my blog for the full announcement: http://shed-skin.blogspot.com Or go straight to the homepage: http://shedskin.googlecode.com Please have a look at the tutorial, try it out, and file any problems in the issue tracker. I'm also always very interested in hearing about potential new programs to add to the example set! Thanks, Mark Dufour -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.7
hi malcolm, Congratulations on your latest release! > thanks! :D > > How well do python extension modules created with ShedSkin work with > applications that expose a GUI, eg. Tkinter or wxPython apps? > quite well I think, but there are some limitations you probably want to be aware of. these are described in the tutorial. > Can ShedSkin code be run in a thread and communicate with the main > interpreter thread through a Queue or Lock? (Or should one use the > multiprocessing module?) > I'm sure things are not thread safe, so you probably want to use the multiprocessing module. how to do this is also described in the tutorial (it's very simple). you probably don't want to use threading anyway for computationally intensive code (because of the GIL). several of the shedskin examples have a GUI, and the new 'pylot' example both has a GUI and uses the multiprocessing module in combination with a shedskin-generated extension module. thanks, mark. -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.7
Hi all, I have just released Shed Skin 0.7, an optimizing (restricted-)Python-to-C++ compiler. It comes with lots of minor fixes and some optimizations, a new Windows package (which includes GCC 4.5), and two nice new examples, for a total of 52 examples at around 14,000 lines (sloccount). Please see my blog for the full announcement: http://shed-skin.blogspot.com Or go straight to the homepage: http://shedskin.googlecode.com Please have a look at the tutorial, try it out, and report issues at the homepage. Thanks, Mark Dufour -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.6
Hi all, I have just released Shed Skin 0.6, an optimizing (restricted-)Python-to-C++ compiler. Most importantly, this release comes with a substantial scalability improvement. It should now be possible to compile programs into several thousands of lines, as shown by the new Commodore 64 emulator example (around 2000 lines, sloccount). Please see my blog for the full announcement: http://shed-skin.blogspot.com Or go straight to the homepage: http://shedskin.googlecode.com Please have a look at the tutorial, try it out, and report issues at the homepage. Thanks, Mark Dufour -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.5
Hi all, I have just released Shed Skin 0.5, an experimental (restricted) Python-to-C++ compiler. Please see my blog for more details about the release: http://shed-skin.blogspot.com/ Thanks, Mark Dufour. -- http://www.youtube.com/watch?v=E6LsfnBmdnk -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.4
Hi all, I have just released Shed Skin 0.4, an experimental (restricted) Python-to-C++ compiler. Please see my blog for more details about the release: http://shed-skin.blogspot.com/ Thanks, Mark Dufour. -- "Overdesigning is a SIN. It's the archetypal example of what I call 'bad taste'" - Linus Torvalds -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.3
Hi all, I have just released Shed Skin 0.3, an experimental (restricted) Python-to-C++ compiler. Please see my blog for more details about the release: http://shed-skin.blogspot.com/ Thanks, Mark Dufour. -- "Overdesigning is a SIN. It's the archetypal example of what I call 'bad taste'" - Linus Torvalds -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.2, an experimental (restricted) Python-to-C++ compiler
Hi all, I have just released version 0.2 of Shed Skin, an experimental (restricted) Python-to-C++ compiler (http://shedskin.googlecode.com). It comes with 7 new example programs (for a total of 40 example programs, at over 12,000 lines) and several important improvements/bug fixes. See http://code.google.com/p/shedskin/wiki/ReleaseNotes for the full changelog. The new example programs consist of Disco, an elegant go player (see http://shed-skin.blogspot.com/2009/07/disco-elegant-python-go-player.html), a larger Voronoi implementation at 800 lines, a TSP algorithm simulating ant colonies, a nicer neural network algorithm and three compressors (Lempel-Ziv, huffman block, and arithmetic). Other than bug fixes for these programs, this release adds some important optimizations. First and foremost, inlining was greatly improved, resulting in potential speedups across the board. Second, loops such as 'for a, b in enumerate/zip(sequence[, sequence])' should now be dramatically faster (also inside list comprehensions), by avoiding allocation of intermediate tuples. Finally, basic list slicing should now be much faster. Please try it out! Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.1.1
Hi all, I have recently released version 0.1.1 of Shed Skin, an experimental (restricted-)Python-to-C++ compiler. This version comes with 5 new example programs (for a total of 35 examples, at over 10,000 lines in total). The most interesting new example is Minilight (http://www.hxa.name/minilight/), a global illumination renderer (or raytracer), that uses triangle primitives and an octree spatial index. According to the Minilight homepage, it becomes up to 100 times faster. Another interesting new example is Peter Norvig's sudoku solver (http://norvig.com/sudoku.html), which unfortunately doesn't become faster but is cool anyway. Please see my blog for more information about the new release: http://shed-skin.blogspot.com The project homepage can be found here: http://code.google.com/p/shedskin/ As I don't get much help, please consider joining the project. See my blog for some ideas on how to help out. More test cases and bug reports would also be very welcome. Thanks, Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.1, an experimental (restricted-)Python-to-C++ Compiler
Hi all, I have recently released version 0.1 of Shed Skin, an experimental (restricted-)Python-to-C++ compiler. Please see my blog for more info about the release: http://shed-skin.blogspot.com Thanks, Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.0.30, an experimental (restricted-)Python-to-C++ Compiler
Hi all, I have just released version 0.0.30 of Shed Skin, an experimental (restricted) Python-to-C++ compiler. Most importantly, this release adds (efficient) support for user-defined classes in generated extension modules, which should make it much easier to integrate compiled code within larger projects. More specifically, compiled classes can now be instantiated on the CPython side, and instances can be passed freely between CPython and Shed Skin without any conversion taking place. (Instances of builtin classes are still (recursively) copied, though, at the moment..) Another major improvement was contributed by FFAO: a new 'set' implementation, directly based on the CPython code. While I haven't tested it on many benchmarks, it is clear that is now much faster, and on one benchmark it even outperforms CPython on my system by about 35%. Other notable changes include complex number support, mapping None to NULL instead of 0 and printing it as 'None', as well as an important type inference fix. With support for user-defined classes in extension modules, it looks like all the major pieces are now there to do a 0.1 release. The only thing I'd really like to do before that, is to improve support for the 'os' module. Please let me know if you'd like to help out here! Hopefully, with many details out of the way, I can have another good look at type inference for 0.2.. Thanks, Mark. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin (restricted) Python-to-C++ compiler 0.0.29
Hi all,
I have just released Shed Skin 0.0.29, with the following changes.
Thanks to those mentioned for helping out!
- datetime implementation (Karel Heyse, Pavel Vinogradov, FFAO, David Marek)
- ConfigParser implementation (suggested by Albert Hofkamp)
- staticmethod and property decorator support (Seo Sanghyeon)
- GCC 4.3 fixes (Seo Sanghyeon, Winterknight)
- FreeBSD, OpenSolaris and 64-bit support
- support for mapping keys('%(key)x' % some_dict)
- improvements to the import mechanism for nested modules (e.g. os.path)
- __init__ is now less of a special case
- many fixes for calling ancestor methods (e.g. __init__)
- all example programs now compile to extension modules
- avoid stack overflows for highly recursive/dynamic types
- re.sub now accepts a replacement function
- remove tuple hash caching (as CPython does not do this)
- many, many bugfixes
This has been a significant release, with many important improvements.
Please see my latest blog entry with more details:
http://shed-skin.blogspot.com/
I would really like to receive more bug reports. Please try out the
new release, and file issues at the project homepage:
http://shedskin.googlecode.com
More coding help is also always welcome. One important feature I'd
really like to have for a 0.1 release is custom class support in
extension modules..
Thanks!
Mark.
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Shed Skin (restricted) Python-to-C++ compiler 0.0.27
Of course I forgot to add the URL: http://shedskin.googlecode.com Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
[ANN] Shed Skin (restricted) Python-to-C++ compiler 0.0.27
Hi all, I have just released Shed Skin 0.0.27. Thanks in large part to the GHOP students, this new release comes with some interesting new goodies: - support for 're', via libpcre (perl-compatible-regular-expressions) - support for 'time' (except for time.strptime under Windows) - basic support for 'staticmethod' and 'property' - support for 'fnmatch', 'glob' (bootstrapped) - improved support for 'os' (POSIX) - OSX support again (including extension modules!) - many fixes for multi-dir/multi-file projects - several builtin optimizations (zip, list(str)..) - type model for 'datetime' (no C++ implementation yet) - split up compiler core, ss.py, into several files - many minor bugfixes As for the 4 new modules (re, time, fnmatch, glob), this means Shed Skin now supports most of the following modules: bisect collections copy fnmatch getopt glob math os os.path random re string sys time I could still really use some help with implementing/bootstrapping implementations for 'datetime' and 'socket', and further improving 'os' (especially under Windows). Note that since the previous release we have a nice tutorial online. It explains in detail how to install and use Shed Skin, how to use it to build (simple) extension modules and how to combine Shed Skin with numpy and parallel processing solutions such as Parallel Python. Thanks, Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin (restricted) Python-to-C++ Compiler 0.0.26
Hi all, I have just released Shed Skin 0.0.26, with the following goodies: -Almost complete support for os.path (bootstrapped using Shed Skin) -Support for collections.defaultdict (completing collections) -Much improved support for the os module (though many methods remain) -Support for 5 of 7 last missing str methods -Added support for getopt.gnu_getopt (bootstrapped) -Improved support for locales -Optimized string addition (a+b+c..) -Much better documentation (tutorial) -Added a Debian package -Squashed many bugs -Moved to Google code hosting Please have a look at my latest blog entry for more details about the release, or visit the new Google code hosting site: http://shed-skin.blogspot.com http://shedskin.googlecode.com Thanks, Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ compiler 0.0.24, 0.0.25
Hi all, I've just released Shed Skin 0.0.25. Together with the (unannounced) 0.0.24 release, there have been some interesting changes. Most importantly perhaps, Shed Skin now caches (most) 1-length strings, which can improve performance dramatically for string-intensive programs. I also performed a long-overdue rewrite of the virtual function detection code, which should work much more reliably now, at least for relatively simple cases :) 0.0.24: -1-length string caching 0.0.25 -improved detection of virtual functions -further set optimizations -fix for extension modules and certain default arguments -exhaustive checking of C++ keywords -fix for some combinations of arguments to min, max -several minor bug fixes As always, I could really use more help in pushing Shed Skin forward. Let me know if you'd like to help out, but are not sure where to begin. The Shed Skin homepage: http://mark.dufour.googlepages.com Thanks, Mark. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
ANN: Shed Skin 0.0.24, 0.0.25
Hi all, I've just released Shed Skin 0.0.25. Together with the (unannounced) 0.0.24 release, there have been some interesting changes. Most importantly perhaps, Shed Skin now caches (most) 1-length strings, which can improve performance dramatically for string-intensive programs. I also performed a long-overdue rewrite of the virtual function detection code, which should work much more reliably now, at least for relatively simple cases :) 0.0.24: -1-length string caching 0.0.25 -improved detection of virtual functions -further set optimizations -fix for extension modules and certain default arguments -exhaustive checking of C++ keywords -fix for some combinations of arguments to min, max -several minor bug fixes As always, I could really use more help in pushing Shed Skin forward. Let me know if you'd like to help out, but are not sure where to begin. Thanks, Mark. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ compiler 0.0.23
Hi all, I have just released Shed Skin 0.0.23. It doesn't contain the type inference scalability improvements I was working on, but it does have quite a few bug fixes and minor feature additions. Here's a list of changes: -support for __iadd__, __imul__ and such (except __ipow__ and __imod__) -some overdue set optimizations -fix for string formatting problem (%% did not always work) -extension module stability fixes -fix for particular inheritance problem -other minor bugfixes, cleanups, and error messages I could really use some systematic help in pushing Shedskin further. Some ideas: -send in bug reports - these are extremely valuable and motivating to me, yet I don't receive many.. -find out why test 148 is currently broken under windows -add datetime, re or socket support -look into supporting custom classes in generated extension modules -write a Shedskin tutorial for 'novice' programmers -systemically test performance and suggest and work on improvements -investigate replacements for std::string and __gnu_cxx::hash_set -perform janitorial-type work in ss.py and lib/builtin.?pp -support extension modules under OSX (OSX gives me accute mental RSI) -add more tests to unit.py Thanks, Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed
hi mike, > Great work. You might want to advertise this on the main site > (currently it states that this is impossible). yes, thank you for reminding me. > You've said somewhere that you didn't/don't plan on working on this > aspect, but it is surely the "killer feature" of shed skin needed to > for it to be able to be used as pyrex is currently (optimizing bits of > larger projects). no I agree it is a very useful feature :-) I was just waiting for someone to step in and help out. when that happened I was motivated enough to fill in the details. > I wish I had time to help, I know it's a bit boring, but I'm always glad to receive bug reports :) A few hours of help looking into adding custom classes to the extension module support, or implementing some library functions, can be very useful too.. (I'm currently getting practically no help at all). >But there is such a large gap betwixt the >twain that such dreaming is but an excercise in fantasy (there's >always pypy). yes, pypy will solve all problems, including world hunger ^^ thanks, mark dufour - shed skin author -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed
hi felix, On 6/29/07, felix seltzer <[EMAIL PROTECTED]> wrote: > does this project include support for pygtk type GUI's? No, it won't work for arbitrary python programs. Shed Skin is currently limited to smallish programs (up to a few hundred lines), that only use a few basic modules (random, math, string, and a few others) and are written in the static subset of Python that Shed Skin supports. A serious pygtk program would probably be too large and too dynamic to compile directly. Instead, you'd typically move some speed-critical functionality to a separate module, and compile this into an extension module or separate program. Look at Shed Skin as something that allows you to write fast extension modules in pure Python, not as something that can convert arbitrary Python programs. Thanks, Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed
Hi all,
I have just released version 0.0.22 of Shed Skin, an experimental
Python-to-C++ compiler. Among other things, it has the exciting new
feature of being able to generate (simple, for now) extension modules,
so it's much easier to compile parts of a program and use them (by
just importing them). Here's the complete changelog:
-support for generating simple extension modules (linux/windows; see README)
-dos text format fix (long overdue)
-improved detection of dynamic types (avoid hanging on them)
-improved overloading (__nonzero__, __int__, __abs__ etc.)
-add str(ing).{capitalize, capwords, swapcase, center, ato*)
-fix string.maketrans
-several other minor bug fixes
For more details about Shed Skin and a collection of 27 programs, at a
total of about 7,000 lines, that it can compile (resulting in an
average speedup of about 39 times over CPython and 11 times over Psyco
on my computer), please visit the homepage at:
http://mark.dufour.googlepages.com
I could really use some help in pushing Shed Skin forward. Please try
the latest release and send in bug reports, or join the project via
the homepage.
Thanks,
Mark Dufour.
On 3/31/07, Mark Dufour <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have recently released version 0.0.20 and 0.0.21 of Shed Skin, an
> optimizing Python-to-C++ compiler. Shed Skin allows for translation of
> pure (unmodified), implicitly statically typed Python programs into
> optimized C++, and hence, highly optimized machine language. Besides
> many bug fixes and optimizations, these releases add the following
> changes:
>
> -support for 'bisect', 'collections.deque' and 'string.maketrans'
> -improved 'copy' support
> -support for 'try, else' construction
> -improved error checking for dynamic types
> -printing of floats is now much closer to CPython
>
> For more details about Shed Skin and a collection of 27 programs, at a
> total of about 7,000 lines, that it can compile (resulting in an
> average speedup of about 39 times over CPython and 11 times over Psyco
> on my computer), please visit the homepage at:
>
> http://mark.dufour.googlepages.com
>
> I could really use more help it pushing Shed Skin further. Simple ways
> to help out, but that can save me lots of time, are to find smallish
> code fragments that Shed Skin currently breaks on, and to help
> improve/optimize the (C++) builtins and core libraries. I'm also
> hoping someone else would like to deal with integration with CPython
> (so Shed Skin can generate extension modules, and it becomes easier to
> use 'arbitrary' external CPython modules such as 're' and 'pygame'.)
> Finally, there may be some interesting Master's thesis subjects in
> improving Shed Skin, such as transforming heap allocation into stack-
> and static preallocation, where possible, to bring performance even
> closer to manual C++. Please let me know if you are interested in
> helping out, and/or join the Shed Skin mailing list.
>
>
> Thanks!
> Mark Dufour.
> --
> "One of my most productive days was throwing away 1000 lines of code"
> - Ken Thompson
>
Mark Dufour.
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed
> You still dream of this, isn't it? Type inference in dynamic languages > doesn't scale. It didn't scale in twenty years of research on > SmallTalk and it doesn't in Python. However there is no no-go theorem type inference sure is difficult business, and I won't deny there are scalability issues, but the situation has improved a lot since back in the smalltalk days. since then, type inference theory has not stood still: agesen' cartesian product algorithm and plevyak's iterative flow analysis (both published around '96) have greatly improved the situation; a 1000-fold or more increase in computer speeds have additionally made actual type inference (experimentation) much more practical. (for anyone interested in the techniques powering shed skin, see agesen and plevyak's phd theses for a relatively recent update on the field.) but in any case, I believe there are several reasons why type inference scalability is actually not _that_ important (as long as it works and doesn't take infinite time): -I don't think we want to do type inference on large Python programs. this is indeed asking for problems, and it is not such a bad approach to only compile critical parts of programs (why would we want to compile PyQt code, for example.) I do think type inference scales well enough to analyze arbitrary programs of up to, say, 5,000 lines. I'm not there yet with Shed Skin, but I don't think it's that far away (of course I'll need to prove this now :-)) -type inference can be assisted by profiling (so dramatically less iterations are necessary to come to a full proof). profiling doesn't have to fully cover code, because type inference fills in the gaps; type inference can also be assisted by storing and reusing analysis results, so profiling only has to be done once, or the analysis can be made easier by running it multiple times during development. because Shed Skin doesn't use profiling or memorization, and I know many things to improve the type analysis scalability, I'm confident it can scale much further than the programs it works for now (see ss- progs.tgz from the homepage for a collection of 27 programs, such as ray tracers, chess engines, sat solvers, sudoku solvers, pystone and richards..). besides, (as john points out I think), there is a difference between analyzing an actual dynamic language and a essentially static language (such as the Python subset that Shed Skin accepts). it allows one to make certain assumptions that make type inference easier. > that prevents ambitious newbies to type theory wasting their time and > efforts. yes, it's probably a waste of time to try and analyze large, actually dynamic, Python programs, but I don't think we should want this at all. computer speeds make Python fast enough for many purposes, and global type inference scalability would demand us to throw out many nice Python features. a JIT compiler seems better here.. where I think Shed Skin and similar tools can shine is in compiling pure Python extensions modules and relatively small programs. having worked on type inference for some time now, with modern techniques :), I see no reason why we can't compile statically typed Python programs, up to several thousands of lines. my analysis works pretty well already (see ss-progs.tgz), and there are many things I can still improve, besides adding profiling and memorization.. > Read the related PEP, John. You will see that Guidos genius is that of > a good project manager in that case who knows that the community works > for him. The trade is that he supplies the syntax/interface and the > hackers around him fantasize about semantics and start > implementations. Not only annotations are optional but also their > meaning. This has nothing to do with VB and it has not even much to do > with what existed before in language design. I think it's more Pythonic to just profile a program to learn about actual types.. mark dufour (Shed Skin author). -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed
> I don't see how that can be--we're talking about a GCC-based compiler, > right? no, Shed Skin is a completely separate entity, that outputs C++ code. it's true I only use GCC to test the output, and I use some GCC- specific extensions (__gnu_cxx::hash_map/hash_set), but people have managed to compile things with Visual Studio or whatever it is called. btw, the windows version of Shed Skin comes with GCC so it's easy to compile things further (two commands, 'ss program' and 'make run' suffice to compile and run some program 'program.py') mark dufour (Shed Skin author). -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed
> Anyway, the only real point is that if there is a concern about the > copyright and licensing of the output of ShedSkin, then we merely need > to ask the author of it to clarify matters and move on with life. With > the exception of GNAT, to date no GPL'd compiler has ever placed a GPL > restriction on its output. Whether this is explicit or implicit doesn't > matter, so long as it's there. it's fine if people want to create non-GPL software with Shed Skin. it is at least my intention to only have the compiler proper be GPL (LICENSE states that the run-time libraries are BSD..) mark dufour (Shed Skin author). -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ Compiler 0.0.21, Help needed
Hi all, I have recently released version 0.0.20 and 0.0.21 of Shed Skin, an optimizing Python-to-C++ compiler. Shed Skin allows for translation of pure (unmodified), implicitly statically typed Python programs into optimized C++, and hence, highly optimized machine language. Besides many bug fixes and optimizations, these releases add the following changes: -support for 'bisect', 'collections.deque' and 'string.maketrans' -improved 'copy' support -support for 'try, else' construction -improved error checking for dynamic types -printing of floats is now much closer to CPython For more details about Shed Skin and a collection of 27 programs, at a total of about 7,000 lines, that it can compile (resulting in an average speedup of about 39 times over CPython and 11 times over Psyco on my computer), please visit the homepage at: http://mark.dufour.googlepages.com I could really use more help it pushing Shed Skin further. Simple ways to help out, but that can save me lots of time, are to find smallish code fragments that Shed Skin currently breaks on, and to help improve/optimize the (C++) builtins and core libraries. I'm also hoping someone else would like to deal with integration with CPython (so Shed Skin can generate extension modules, and it becomes easier to use 'arbitrary' external CPython modules such as 're' and 'pygame'.) Finally, there may be some interesting Master's thesis subjects in improving Shed Skin, such as transforming heap allocation into stack- and static preallocation, where possible, to bring performance even closer to manual C++. Please let me know if you are interested in helping out, and/or join the Shed Skin mailing list. Thanks! Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: To count number of quadruplets with sum = 0
> FWIW, the original program can also be compiled with Shed Skin (http:// > mark.dufour.googlepages.com), an experimental (static-)Python-to-C++ > compiler, resulting in a speedup of about 8 times for a single test > with 500 tuples. here's a slightly modified version that works with > Shed Skin CVS at least: after optimizing dicts a bit for Shedskin 0.0.21 (http:// mark.dufour.googlepages.com), the speedup for this program is now about 16.5 times for the same test. Thanks, Mark Dufour (Shed Skin author - send me bug reports!) -- http://mail.python.org/mailman/listinfo/python-list
Re: To count number of quadruplets with sum = 0
Paul Rubin wrote:
> "n00m" <[EMAIL PROTECTED]> writes:
> > Two first outputs is of above (your) code; next two - of my code:
>
> Yeah, I see now that we both used the same algorithm. At first glance
> I thought you had done something much slower. The 10 second limit
> they gave looks like they intended to do it about this way, but with a
> compiled language. 68 seconds isn't so bad for 4000 entries in pure
> CPython. Next thing to do I think is use psyco or pyrex.
FWIW, the original program can also be compiled with Shed Skin (http://
mark.dufour.googlepages.com), an experimental (static-)Python-to-C++
compiler, resulting in a speedup of about 8 times for a single test
with 500 tuples. here's a slightly modified version that works with
Shed Skin CVS at least:
import time
t = time.clock()
q,w,e,r,sch,h = [],[],[],[],0,{}
f = open("m33.txt","rt")
n = int(f.readline())
for o in range(n):
row = [int(x) for x in f.readline().split()]
q.append(row[0])
w.append(row[1])
e.append(row[2])
r.append(row[3])
f.close()
for x in q:
for y in w:
if h.has_key(x+y):
h[x+y] += 1
else:
h[x+y] = 1
for x in e:
for y in r:
sch += h.get(-(x+y),0)
print sch
print time.clock() - t
Thanks,
Mark Dufour (Shed Skin author - send me bug reports!)
--
http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ Compiler
Hi all, I have just released version 0.0.19 of Shed Skin, an optimizing Python-to-C++ compiler. It allows for translation of pure (unmodified), implicitly statically typed Python programs into optimized C++, and hence, highly optimized machine language. This latest release adds basic support for iterators and generators, as well as a full implementation of the random module (by converting it to C++ from a Python implementation), among other things. For more details, and a collection of 26 programs, at a total of about 7,000 lines, that work with Shed Skin (resulting in an average speedup of about 40 times over CPython and 11 times over Psyco on my computer), please visit the homepage at: http://mark.dufour.googlepages.com Thanks! Mark Dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ Compiler
hi all, I have just released Shed Skin 0.0.18. besides many fixes and optimizations, this release should work on OSX and 64-bit systems (thanks john, larry, gustavo and denis!) more interestingly, I collected 25 'largish' programs (at a total of more than 6,000 lines!) that work fine with Shed Skin. these can be downloaded from the Shed Skin homepage: http://mark.dufour.googlepages.com please let me know if you try out the latest release, and encounter any problems or have any wishes. thanks, mark. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: some OT: how to solve this kind of problem in our program?
[EMAIL PROTECTED] wrote: > Using Psyco this version is much faster, you can test it on your PC > compared to the other one (the whole running time, Psyco compilation > too): FWIW, the CVS version of Shed Skin optimizes this exact program a bit further than Psyco: Psyco: 0.66 s Shed Skin: 0.30 s Thanks, Mark Dufour. -- Shed Skin author, http://mark.dufour.googlepages.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin 0.0.15
Thanks to those that sent in bug reports. This is really, really useful.
I already released 0.0.16, with the following improvements:
-added frozenset
-time.sleep now works on WIN32
-constant-string expressions and __doc__ attributes are made into nice
C++ comments
-added --nowrap optimization option to ss.py (disables checking for
negative indices)
-several minor bug-fixes reported by users of 0.0.15
Thanks,
Mark.
On 12/9/06, Mark Dufour <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> After getting bogged down with work for a few months, I'm finally back
> to Shed Skin development. I have just released 0.0.15, with the
> following changes:
>
> -python2.5 support/compatibility
> -any, all, conditional expression support
> -moved libs to 'lib' dir; made it easier to add modules (see README)
> -os.stat, os.path.{split, splitext, isfile, isdir, islink, exists}
> compiled from PyPy source
> -os.{chdir, rename, stat, lstat} added
> -fnmatch module added
> -random.{sample, seed} added
> -several important bugfixes (e.g. except getopt.GetoptError)
>
> There's more information about this release and the current state of
> Shed Skin on my blog:
>
> http://shed-skin.blogspot.com/
>
> I also started a page on Wikipedia. Maybe a text like this should
> replace the one on the Shed Skin website:
>
> http://en.wikipedia.org/wiki/Shed_Skin
>
> Projects for the near future are getting 'shuffle-db' working (a
> 600-line program to rebuild the database on an ipod shuffle; see my
> blog), and converting the 're' module from the PyPy implementation to
> C++ using Shed Skin.
>
> Please try out the new release, and let me know about any
> problems/wishes/successes. As always, I am very happy with minimized
> pieces of code that fail to compile or should produce a (better) error
> or warning message.
>
> http://mark.dufour.googlepages.com
>
>
> Mark.
> --
> "One of my most productive days was throwing away 1000 lines of code"
> - Ken Thompson
>
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-list
Shed Skin 0.0.15
Hi all,
After getting bogged down with work for a few months, I'm finally back
to Shed Skin development. I have just released 0.0.15, with the
following changes:
-python2.5 support/compatibility
-any, all, conditional expression support
-moved libs to 'lib' dir; made it easier to add modules (see README)
-os.stat, os.path.{split, splitext, isfile, isdir, islink, exists}
compiled from PyPy source
-os.{chdir, rename, stat, lstat} added
-fnmatch module added
-random.{sample, seed} added
-several important bugfixes (e.g. except getopt.GetoptError)
There's more information about this release and the current state of
Shed Skin on my blog:
http://shed-skin.blogspot.com/
I also started a page on Wikipedia. Maybe a text like this should
replace the one on the Shed Skin website:
http://en.wikipedia.org/wiki/Shed_Skin
Projects for the near future are getting 'shuffle-db' working (a
600-line program to rebuild the database on an ipod shuffle; see my
blog), and converting the 're' module from the PyPy implementation to
C++ using Shed Skin.
Please try out the new release, and let me know about any
problems/wishes/successes. As always, I am very happy with minimized
pieces of code that fail to compile or should produce a (better) error
or warning message.
http://mark.dufour.googlepages.com
Mark.
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-list
Re: slow non-blocking reads
interestingly, leaving out the fcntl stuff makes it work much faster.
it seems to block only sometimes now, for just a moment, but on the
whole the performance is acceptable now.
On 6/29/06, Mark Dufour <[EMAIL PROTECTED]> wrote:
> hello all,
>
> I am trying to fire up a child process using os.popen2, and have the
> parent and child communicate in a non-blocking fashion. it works, but
> somehow it's unbearably slow. the following simulates a blocking
> readline:
>
> import os, fcntl
>
> fi, fo = os.popen2('./child')
> fcntl.fcntl(fo.fileno(), fcntl.F_SETFL, os.O_NONBLOCK)
>
> def getline():
> line = ''
> while 1:
> try:
> line += os.read(fo.fileno(), 1)
> if line.endswith('\n'):
> return line
> except OSError:
> pass
>
> print getline()
>
> while 1:
> fi.write('echo echo echo\n')
> fi.flush()
> print getline()
>
> and this is the child process, written in C:
>
> tcgetattr(0, &tty);
> tty.c_lflag &= ~ICANON;
> tty.c_cc[VTIME] = 0;
> tty.c_cc[VMIN] = 0;
> tcsetattr(0, TCSADRAIN, &tty);
>
> fds[0].fd = 0;
> fds[0].events = POLLIN;
>
> fcntl(0, F_SETFL, O_NONBLOCK);
>
> printf("start\n");
> fflush(stdout);
>
> while(1) {
> if( poll(fds, 1, 0) > 0) {
> if((fds[0].fd == 0) && (fds[0].revents & POLLIN)) {
> read(0, &c, 1);
>
> printf("%c", c);
> fflush(stdout);
> }
> }
> }
>
> the child sends a 'start' message and then echoes the parent.
>
> any thoughts about why this runs extremely slowly?
>
>
> thanks!
> mark dufour.
> --
> if vars: self.output('; '.join([self.type(var)+' '+name for (name,var)
> in vars.items()])+';')
>
--
if vars: self.output('; '.join([self.type(var)+' '+name for (name,var)
in vars.items()])+';')
--
http://mail.python.org/mailman/listinfo/python-list
slow non-blocking reads
hello all,
I am trying to fire up a child process using os.popen2, and have the
parent and child communicate in a non-blocking fashion. it works, but
somehow it's unbearably slow. the following simulates a blocking
readline:
import os, fcntl
fi, fo = os.popen2('./child')
fcntl.fcntl(fo.fileno(), fcntl.F_SETFL, os.O_NONBLOCK)
def getline():
line = ''
while 1:
try:
line += os.read(fo.fileno(), 1)
if line.endswith('\n'):
return line
except OSError:
pass
print getline()
while 1:
fi.write('echo echo echo\n')
fi.flush()
print getline()
and this is the child process, written in C:
tcgetattr(0, &tty);
tty.c_lflag &= ~ICANON;
tty.c_cc[VTIME] = 0;
tty.c_cc[VMIN] = 0;
tcsetattr(0, TCSADRAIN, &tty);
fds[0].fd = 0;
fds[0].events = POLLIN;
fcntl(0, F_SETFL, O_NONBLOCK);
printf("start\n");
fflush(stdout);
while(1) {
if( poll(fds, 1, 0) > 0) {
if((fds[0].fd == 0) && (fds[0].revents & POLLIN)) {
read(0, &c, 1);
printf("%c", c);
fflush(stdout);
}
}
}
the child sends a 'start' message and then echoes the parent.
any thoughts about why this runs extremely slowly?
thanks!
mark dufour.
--
if vars: self.output('; '.join([self.type(var)+' '+name for (name,var)
in vars.items()])+';')
--
http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ Compiler - Summer of Code?
Hello all, As Bearophile pointed out, I have just released Shed Skin 0.0.8. For those of you that do not know Shed Skin, it is an optimizing Python-to-C++ compiler, that allows for translation of pure (unmodified) Python programs into optimized machine language. The speed of generated code is typically 2-40 times, 12 on average, faster than when using Psyco, and 2-220 times, 45 on average, than when using CPython, for a sizeable set of benchmarks (such as a raytracer, chess player, othello player, neural network sim, sat solver, several sudoku solvers..) See http://mark.dufour.googlepages.com for a more detailed introduction to Shed Skin, its current limitations, and a link to my Master's Thesis, which contains more precise results and an explanation of how the compiler works. Now that I have released a fairly clean and stable (but still very much alpha!) version of my compiler, I would like to invite other people to join the project. Seeing that the SoC application deadline for this year is only in about a week (:P), this would be a nice way to help out and get started in SS development. Note that I did a SoC project on SS last year, which has improved it tremendously. Two important aspects that still need to be investigated are memory optimizations (e.g. transforming heap allocation into stack- and static preallocation), more efficient string support (rather than using the inefficient C++ STL string type) and looking at integration with the standard library and calling compiled code from Python. Note that especially memory optimizations would also be an interesting Master's Thesis topic. Again, see http://mark.dufour.googlepages.com for more details about possible ways to help out. Please let me know if you are even remotely interested :-) Otherwise, a simple way to also help out, is to send me bug reports of small code fragments that SS does not compile correctly, or you can just send me complete programs. Bug reports are always motivating, make my work more time-efficient, and are the best way to getting your own programs supported. Thanks. Mark. -- "How should I know if it works? That's what beta testers are for. I only coded it." - Linus Torvalds -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin (Python-to-C++ Compiler) 0.0.5.9
Hello Python lovers, I have just released Shed Skin 0.0.5.9. It's almost where I want it to be for 0.0.6. What remains to be coded is some kind of connection to the standard library (probably a simple one at first: working only for 'opaque handlers'). I also want to improve cases where ints and floats are mixed, since this is quite common. Some major changes: -basic exception handling (support for custom ones, and for some builtins such as ValueError, KeyError and AssertionError; this will allow for implementation of iterator objects later on) -some basic inheritance (no multiple inheritance yet, or weird stuff; this enabled me to add the 340-line pygmy raytracer to the test set. it becomes about 40 times faster here..) -keyword arguments (this has not been tested very well yet - let me know about any problems) -many missing minor 'set' features, thanks to reports by bearophile (it should be practically complete now. the whole set of builtins is nearing completion :D time to start optimizing stuff..) -many, many bugfixes again, again mostly thanks to bearophile I added four new 'big' programs to the test set that (with some minor modifications) work now: a tic-tac-toe player for arbitrary size boards, a simple genetics algorithm, a linear algebra program and the mentioned raytracer. Finally, the README has been improved again, though it's still pretty bad. After the release of 0.0.6 I plan to create a web site with performance comparisons between CPython, Psyco and Shed Skin (perhaps even PyPy :P), because quite some interesting programs compile now, and Shed Skin is usually a lot faster than Psyco, except when Python builtins are the bottleneck. I guess some more STL magic is required here.. Let the small code fragments that fail flowing! Mark. -- "Never trust a computer you can't throw out the window" - Steve Wozniak -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ compiler 0.0.5 released!
Hi all, I have just released Shed Skin 0.0.5. It fixes many bugs and adds many minor features to the Python builtins, most notably, the 'set' class. There have also been some optimizations on the C++ side. Finally, the README now better explains the compiler's limitations, and a TODO file has been added containing open bugs. I would like to invite anyone to try out this new version, especially if there were problems with 0.0.4. If you encounter a bug or missing feature, please send me a small code fragment that exhibits the problem, so I can fix it or add it to the TODO. If you are a C++ programmer, please consider helping out on the C++ side, by sending in patches to improve the C++ implementation of the Python builtins! For 0.0.6 (a feature release!), the following things are on my list: - Basic inheritance support - Automating the connection to the Python standard library - Better error messages for things SS doesn't handle (Finally?!) Shed Skin can be downloaded here: http://shedskin.sourceforge.net. I also maintain a blog about the project: http://shed-skin.blogspot.com. Thanks!! Mark. -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin Python-to-C++ Compiler 0.0.3 Release: some fixes, 3 MB Windows package
Hi all, Thanks to the people trying out Shed Skin 0.0.2 and letting me know about several problems they encountered. I have released an updated version, 0.0.3. It contains some fixes, adds support for several builtin functions (sorted, xrange..) and the Windows version is now a mere 3 MB, instead of 20 :-) Shed Skin's main purpose is to optimize algorithmic-like Python code, by applying advanced global type inference techniques. It does not support e.g. exceptions (yet), and there are currently some other limitations. Importing modules requires some extra work on the part of the user (see the README for details,) although some imports are currently supported (some math, random functions and sys.argv.) What you gain by using Shed Skin is highly optimized code (industrial C++ compiler), independent of any virtual machine. It is also possible to create highly optimized extension modules this way. I invite anyone to try not too large algorithmic-like programs (e.g. AI stuff) with Shed Skin and to let me know if there are any problems. Even though 129 test programs already work well (6 of which are larger than 100 lines), there are still many unimplemented minor features that I can easily fix, provided someone shows me a nice use case. Thanks to the people that have sent me failing code snippets before! http://shedskin.sourceforge.net http://shed-skin.blogspot.com Thanks! Mark Dufour. -- http://mail.python.org/mailman/listinfo/python-list
Release of Shed Skin 0.0.2: Easy Windows/OSX Installation
Hi! Shed Skin is an experimental Python-to-C++ compiler. Along with GNU/Linux, version 0.0.2 should now also install easily under Windows 2000/XP and OSX. Please give it a try and let me know if there are still some problems. If you would like to help me improve Shed Skin, please send me small code snippets, preferrably extracted from real-life use cases, that the compiler has problems with. Thanks to everyone who has helped me out, especially Khalid, Leonardo and Luis here on python-list, and Denis de Leeuw Duarte right here in the street :-) http://shedskin.sourceforge.net http://shed-skin.blogspot.com thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
Release of Shed Skin 0.0.2: Easy Windows/OSX Installation
Hi! Shed Skin 0.0.2 is up on SourceForge. It should install easily under Windows 2000/XP and OSX. Please give it a try and let me know if there are still some problems. If you would like to help me improve Shed Skin, please send me small code snippets, preferrably extracted from real-life use cases, that the compiler has problems with. Thanks to everyone who has helped me out, especially Khalid, Leonardo and Luis here on python-list, and Denis de Leeuw Duarte right here in the street :-) http://shedskin.sourceforge.net http://shed-skin.blogspot.com thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin under Windows and OSX
> *** success: small factorization program by Rohit Krishna Kumar 124
> *** no failures, yay!
>
>
> :)
>
> Well done. So what was causing that crash in test '__class__ and
> __name__ attributes' after all?
Well, I did something like this:
class_ c(..);
class_ *cp = &c;
class list {
list() {
this->class = cp;
}
}
constant_list = new list(..);
Now, depending on the order of things, I think this->class became
somewhat undefined. In any case, putting all initializations in the
right order in an initialization function called from main() fixed the
problem.
The problem with test 85 was that it should not actually be passed to
g++, since it is indeed incorrect code :-) However, because of some
bug in unit.py, on sys.platform 'win32' g++ would always be called.
Thanks again for your help. Your Makefile made it very easy for me to
create a Windows package. I'm glad to learn about Mingw too.. very
nice.
> I'll also try to test it on Win98.
I think you said the GC wouldn't work in this case..? Anyway, I've had
my share of Windows for a while.. I would be really glad if somebody
else could look into this.. :)
Have you tried compiling any code of your own yet..?
thanks!
mark.
--
http://mail.python.org/mailman/listinfo/python-list
Shed Skin under Windows and OSX
> By the way, I read in your blog that you would be releasing a windows > intaller soon. > Have you, or anyone else, managed to do it? I just finished making a 20 MB (!) package for Windows XP (I'm not sure which older versions of Windows it will run on.) It includes the Boehm garbage collector and a C++ compiler (MingW), which hopefully will make it really easy to create executables. However, I'm not releasing it until somebody with XP can test it for me :-) If you'd like to try what I have so far, please download http://kascade.org/shedskin-0.0.2.zip, unzip it and follow some simple steps in the README file. I would really like to know about anything that doesn't work, or is unclear! BTW, I also fixed all OSX problems, but I'm waiting for a friend to give it a final test. What kind of program would you like to compile? thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
>You have achieved so much with the first release of Shed Skin that it's >strange to see you apparently trying to argue that exceptions aren't >necessary when in fact they are such a fundamental part of Python's >philosophy. To be honest, I am a relative newcomer to Python, and Shed Skin is the first large program I have written in it. My background is mostly writing algorithms in C, and I don't think I've ever (voluntarily) caught an exception in my life, or that doing so could have made my code any cleaner. So for me personally, and for the types of programs I usually write, I'm still not sure if they will ever be very useful. I guess I have just naturally ignored them.. :-) Thank you for stressing the importance of exceptions in Python in general. I'm always happy to learn more about the language and its philosophy.. thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
Re: First release of Shed Skin, a Python-to-C++ compiler.
> You forgot to check for an error when: > o when you wrote f.error [attribute "error" might not exist e.g. f is >None] > o you called str(f.error) [might contain unicode characters that can't > be converted to a string using the default > encoding] > o when you used the % operator [format string might be wrong] > And, of course, pretty much every expression can result in a memory error. I don't mind the program bailing out in such a case and telling me where it went wrong, so I can fix the problem. I just don't really see the need for catching exceptions yourself. Especially not in well-tested code, potentially to be compiled. > Exception handling is a boon because almost EVERY expression that you > write can result in a error and checking each one is tedious in the > extreme. So people forget and then their programs exhibit very odd > behavior that is very difficult to debug. What do you mean odd behaviour? If they don't catch exceptions, the program will bail out, showing what went wrong, yeah? > If you look at the Python C source, you'll notice that probably 50% of > the code is devoted to error handling (that was a guess). That's a lot of error handling.. thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
>> Hehe. Okay. It will probably always be the case that you have to lose >> some Python features if you want the code to run really fast. I >> suppose PyPy's restricted Python subset doesn't support duck typing >> either. Luckily not all code is performance critical, or you could >> just try and optimize some performance critical part. But anyway, I'm >> starting to understand that Shed Skin should probably support >> exceptions wherever possible :-) >Ok - the point I was trying to make was that exceptions were pretty >integral to Python. I accept that losing the more dynamic features of >Python for 'compilation' is a possibly worthwhile tradeoff. Shed Skin's main use will be in algorithmic-like code, which is also in most need of optimization. Typically such code is not very dynamic, or uses many exceptions, if any. It may be the case that most programs written in Python are not algorithmic-like at this point, which would be logical, since Python is traditionally not one of the fastest languages.. In that case applying Shed Skin to existing programs may not be very useful in most cases. But in any case, exceptions are not really dynamic (I think..) so, yeah, they should be supported.. >How easy is it going to be to call your c++ code from Python (and vice >versa) ? I haven't really thought deeply about this, but I guess it shouldn't be too hard to use existing C++/Python bridges there. However, I have no experience at all in this area.. (hint hint) thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
Using Shed Skin under Windows or OSX
Hello all, My apologies to everyone who has tried Shed Skin under Windows or OSX, and could not get it to run. I have to stress that it really is experimental software, and certainly not ready for production use at this point. However, that is not an excuse for a vague and/or too difficult installation prodedure. I hope to find and spend some time behind Windows and OSX boxes this week, to fix any problems and hopefully make it easy to install the compiler on them. For now, two very helpful persons have posted instructions on how to get Shed Skin sort of working under either operating system (there are still some problems with the unit tests..) http://mail.python.org/pipermail/python-list/2005-September/298697.html http://www.blogger.com/comment.g?blogID=14063458&postID=112636132130703717 thanks! mark. Mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
>I am reluctant to attempt an arduous installation on Windows, but if >Mr. Dufour or someone else could create a web site that would let you >paste in Python code and see a C++ translation, I think this would >expand the user base. Alternatively, a Windows executable would be >nice. The web site is a great idea, thanks. Maybe I will get to that, but I have so much other things on my TODO list.. The source code of the compiler can be downloaded, so anyone is free to tinker with it. The problem of making a Windows executable is that the compiler itself makes Windows executables, and therein lies the problem. It would be nice if somebody would come up with a complete package, because I have no access to Windows nor would I know how to approach that.. thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
>In general it's considered quite pythonic to catch exceptions :-) >It's a particularly useful way of implementing duck typing for example. >I'm not sure if I've got *any* code that doesn't use exceptions >somewhere Hehe. Okay. It will probably always be the case that you have to lose some Python features if you want the code to run really fast. I suppose PyPy's restricted Python subset doesn't support duck typing either. Luckily not all code is performance critical, or you could just try and optimize some performance critical part. But anyway, I'm starting to understand that Shed Skin should probably support exceptions wherever possible :-) The main goal of Shed Skin is to be able to specify C++-like code at a higher level, not to be able to optimize arbitrary Python programs.. :-) For the kinds of things I write (algorithmic-like code), I really don't need the full flexibility of Python. It's just great to be able to leave out type declarations, and to use the beautiful Python syntax. >;-) >All the best, thanks! mark. Fuzzyman http://www.voidspace.org.uk/python/index.shtml > > thanks! > mark. -- http://mail.python.org/mailman/listinfo/python-list
Re: First release of Shed Skin, a Python-to-C++ compiler.
On 9/12/05, Brian Quinlan <[EMAIL PROTECTED]> wrote: > Mark Dufour wrote: > > The latter is certainly my goal. I just haven't looked into supporting > > exceptions yet, because I personally never use them. I feel they > > should only occur in very bad situations, or they become goto-like > > constructs that intuitively feel very ugly. In the 5500 lines of the > > compiler itself, I have not needed to use a single exception. For > > example, I prefer to check whether a file exists myself, rather than > > executing code that can suddenly jump somewhere else. There's probably > > some use for exceptions, but I don't (want to?) see it. > > I don't understand your example here. When you check that a file exists, > you feel safe that openning it will succeed? What if: > > o you don't have permission to open the file > o the file is deleted in the time between you checking for it's >existance and opening it (possible race condition) > o the system doesn't have sufficient resources to open the file >e.g. too many open file handles > o the file is already open with exclusive read/write permission You're right, I don't feel safe about that. It's a bad example. I just prefer error codes, because the code usually becomes cleaner (at least to me). I would really like it if I could do something like this: f = file(name) if not f: print 'error opening file %s: %s', name, str(f.error) sys.exit() Error codes may be more work in some cases, but I really like the (subjectively) cleaner code. Again, exceptions are probably useful in some programs, but I wouldn't know.. :) thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
>First the good news: ShedSkin (SS) more or less works on Windows. After >patching gc6.5 for MinGW, building it, and testing it on WinXP with >some succuess, and after patching my local copy of SS, I can get the >test.py to compile from Python to C++, and it seems that I can get >almost all the unit tests in unit.py to pass. Thank you so much for your efforts! I will try to download your patches this afternoon on a roommate's Windows computer, and try to see if I can fix the remaining tests. >Moreover, and since the GC system you used only works in "recent >versions of Windows", it follows that this solution will not work in >all versions. I tested it on Win98 and both GC tests and SS's unit.py >tests crash; although SS can still seem to compile the tests to C++. Thanks!! Since adding GC support took about 10 lines of C++ code, I guess it won't be hard to switch to a different system.. I'll try and see if I can add support for a version that works with Win98.. BTW if anyone is interested in running Shed Skin under OSX.. I got this comment on my blog (http://shed-skin.blogspot.com) (why doesn't everybody just run Gentoo? :P) >Wow, very cool. Congratulations! > >Here's what I had to do to get it working on the Mac (OS X 10.4): > >1. Install the garbage collector from >http://www.hpl.hp.com/personal/Hans_Boehm/gc/ > >2. Add #include above #include in builtin_.hpp > >3. Change makelib to: g++ -dynamiclib -o libss.dylib builtin_.cpp sets_.cpp >random_.cpp math_.cpp copy_.cpp -lgc -lm > >4. Edit ss to use the appropriate path > >5. Use python 2.4 instead of the version 2.2 or 2.3 that comes with OS X (in my >case, I just had to put /usr/local at the start of my path) > >6. Run ./ss test.py > >7. Compile the resulting cpp file with: g++ -L. test.cpp -lss -lgc > >8. Run ./a.out and watch in awe. thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
>Obviously, neither the 0 nor the message following should have been >displayed. It's a pity that this assumption was made, but given the short >time the project's been going I can understand it, hopefully Mark will >continue towards greater python compliance :) The latter is certainly my goal. I just haven't looked into supporting exceptions yet, because I personally never use them. I feel they should only occur in very bad situations, or they become goto-like constructs that intuitively feel very ugly. In the 5500 lines of the compiler itself, I have not needed to use a single exception. For example, I prefer to check whether a file exists myself, rather than executing code that can suddenly jump somewhere else. There's probably some use for exceptions, but I don't (want to?) see it. Seeing how often exceptions are used by other people though, it's probably one of the first things I should look into.. :-) thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
>> After nine months of hard work, I am proud to introduce my baby to the >> world: an experimental Python-to-C++ compiler. >Wow, looks really cool. But why that instead of Pypy? I agree with anyone that a JIT compiler that supports the full Python semantics (which I thought to be the goal of PyPy?) is probably the best long term solution. It will really be a lot of work, however, and in general probably result in slower code than what my compiler produces, when it works (because of run-time overheads, lack of global optimizations.) Considering that Shed Skin does what it does in only about 7500 lines (5500 without C++ implementations of builtins), and is extreme in both the requirements it puts on the compiler and in the speed of the resulting code, for me personally it is just a very appealing alternative to investigate (I like extremes :-)) It should work for many programs of the type I usually write (algorithms, compilers..), so it's also a case of scratching my own itch. thanks! mark. -- http://mail.python.org/mailman/listinfo/python-list
First release of Shed Skin, a Python-to-C++ compiler.
After nine months of hard work, I am proud to introduce my baby to the
world: an experimental Python-to-C++ compiler. It can convert many
Python programs into optimized C++ code, without any user intervention
such as adding type declarations. It uses rather advanced static type
inference techniques to deduce type information by itself. In
addition, it determines whether deduced types may be parameterized,
and if so, it generates corresponding C++ generics. Based on deduced
type information, it also attempts to convert heap allocation into
stack and static preallocation (falling back to libgc in case this
fails.)
The compiler was motivated by the belief that in many cases it should
be possible to automatically deduce C++ versions of Python programs,
enabling users to enjoy both the productivity of Python and the
efficiency of C++. It works best for Python programs written in a
relatively static C++-style, in essence enabling users to specify C++
programs at a higher level.
At the moment the compiler correctly handles 124 unit tests, six of
which are serious programs of between 100 and 200 lines:
-an othello player
-two satisfiability solvers
-a japanese puzzle solver
-a sudoku solver
-a neural network simulator
Unfortunately I am just a single person, and much work remains to be
done. At the moment, there are several limitations to the type of
Python programs that the compiler accepts. Even so, there is enough of
Python left to be able to remain highly productive in many cases.
However, for most larger programs, there are probably some minor
problems that need to be fixed first, and some external dependencies
to be implemented/bridged in C++.
With this initial release, I hope to attract other people to help me
locate remaining problems, help implement external dependencies, and
in the end hopefully even to contribute to the compiler itself. I
would be very happy to receive small programs that the compiler does
or should be able to handle. If you are a C++ template wizard, and you
would be interested in working on the C++ implementation of builtin
types, I would also love to get in contact with you. Actually, I'd
like to talk to anyone even slightly interested in the compiler, as
this would be highly motivating to me.
The source code is available at the following site. Please check the
README for simple installation/usage instructions. Let me know if you
would like to create ebuild/debian packages.
Sourceforge site: http://shedskin.sourceforge.net
Shed Skin blog: http://shed-skin.blogspot.com
Should you reply to this mail, please also reply to me directly. Thanks!
Credits
Parts of the compiler have been sponsored by Google, via its Summer of
Code program. I am very grateful to them for keeping me motivated
during a difficult period. I am also grateful to the Python Software
Foundation for chosing my project for the Summer of Code. Finally, I
would like to thank my university advisor Koen Langendoen for guiding
this project.
Details
The following describes in a bit more detail various aspects of the
compiler. Before seriously using the compiler, please make sure to
understand especially its limitations.
Main Features
-very precise, efficient static type inference (iterative object
contour splitting, where each iteration performs the cartesian product
algorithm)
-stack and static pre-allocation (libgc is used as a fall-back)
-support for list comprehensions, tuple assignments, anonymous funcs
-generation of arbitrarily complex class and function templates
(even member templates, or generic, nested list comprehensions)
-binary tuples are internally analyzed
-some understanding of inheritance (e.g. list(dict/list) becomes
list>)
-hierarchical project support: generation of corresponding C++
hierarchy, including (nested) Makefiles; C++ namespaces
-annotation of source code with deduced types
-builtin classes, functions (enumerate, sum, min, max, range, zip..)
-polymorphic inline caches or virtual vars/calls (not well tested)
-always unbox scalars (compiler bails out with error if scalars are
mixed with pointer types)
-full source code available under the MIT license
Main Limitations/TODO's
-Windows support (I don't have Windows, sorry)
-reflection (getattr, hasattr), dynamic inheritance, eval, ..
-mixing scalars with pointer types (e.g. int and None in a single variable)
-mixing unrelated types in single container instance variable other
than tuple-2
-holding different types of objects in tuples with length >2;
builtin 'zip' can only take 2 arguments.
-exceptions, generators, nested functions, operator overloading
-recursive types (e.g. a = []; a.append(a))
-expect some problems when mixing floats and ints together
-varargs (*x) are not very well supported; keyword args are not supported yet
-arbitrary-size arithmetic
-possible non-termination ('recursive customization', have not
encountered it yet)
-profiling will be required for sca
