AeroEng43 / shedskin

Automatically exported from code.google.com/p/shedskin
0 stars 0 forks source link

compile shedskin or speedup with compiling of modules #40

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I tried to run "shedskin shekskin"^^

In any files are "import compiler".... But only needed in one module!

This patch corrects this (tests fixes for 0.2 and 0.2.1 are currently
failing here, but with master also -> no problem (maybe another problem))

Another bug is new:

running: shedskin cpp
*** SHED SKIN Python-to-C++ Compiler 0.2 ***
Copyright 2005-2009 Mark Dufour; License GNU GPL version 3 (See LICENSE)

*ERROR* shared.py:143: function/class redefinition is not supported ('class_')

"class_" is in shared.py and in builtin.py, possibly this is resulting this
error

Original issue reported on code.google.com by thomas.s...@gmail.com on 23 Aug 2009 at 5:26

Attachments:

GoogleCodeExporter commented 8 years ago
thanks! this kind of patch is much appreciated, even though it may seem 
trivial. I
committed it, and cleaned up the imports a bit further. SS is now under 6,900 
lines
again, yay :) 

btw, if possible, could you please automatically remove the 'a/' and 'b/' 
prefixes
from your patches, or tell me how to your patches directly with 'patch'..?

I will have a look at the 'shedskin cpp' bug later, but note that shedskin 
won't ever
be capable of compiling itself, because of dynamic typing (mainly from using the
compiler package visitor pattern) and unsupported imports. it may be possible to
compile the type inference part though, but I currently don't feel like that 
would be
worth the effort. 

Original comment by mark.duf...@gmail.com on 24 Aug 2009 at 3:45

GoogleCodeExporter commented 8 years ago
I just tried to apply the patches and it worked…

just "patch < 0001-delete-some-import-compiler-s-as-they-are-not-needed.patch" 
and
that's it.
Reading the manuals a -p1 should delete a/ and b/ if nesessary, but, it applied 
here
directly. (Even without deleting the commit comments above.)

patch --version
patch 2.5.4
Copyright 1984-1988 Larry Wall
Copyright 1989-1999 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert

Original comment by thomas.s...@gmail.com on 25 Aug 2009 at 2:25

GoogleCodeExporter commented 8 years ago
okay, I see, thanks! I was using -p0 I think, out of habit. now I know what that
means.. :)

Original comment by mark.duf...@gmail.com on 25 Aug 2009 at 9:02

GoogleCodeExporter commented 8 years ago
You are welcome ;-)

This patch solves the doubled mentioning of 'class_' by simply renaming it 
everywhere
to 'class__' (all tests are ok, except the latest 2, as before too)

I propose to rename it to something like 'collector' because it seems this class
collects any funcs, virtuals and so on... This would help understanding the 
code (at
least for me^^)

Original comment by thomas.s...@gmail.com on 25 Aug 2009 at 10:56

Attachments:

GoogleCodeExporter commented 8 years ago
instances of 'class_' collect information about python classes, much like the
'variable' and 'function' classes around it do this for variables and 
functions.. so
if 'class' wasn't a keyword, I feel 'class' would be the best name.

I don't think it would help to rename it, as redefining 'class_' is still 
illegal
after, and letting shedskin compile itself won't ever be possible..

I forgot if I already asked, but can you see why test 186 is failing..?

Original comment by mark.duf...@gmail.com on 28 Aug 2009 at 3:12

GoogleCodeExporter commented 8 years ago
Yes.
-> from sys import maxint as MAXINT
   a = MAXINT
On python this is 9223372036854775807, on c++ only 2^31 (for 32-bit integers) =
2147483647.

long int instead of int in c++ should solve this.

Atm, I'm thinking of improving the testsuite, that we can test more cases in 
one test
and know which excectly was failing. Would be nice, and easier to detect.

Original comment by thomas.s...@gmail.com on 29 Aug 2009 at 4:17

GoogleCodeExporter commented 8 years ago
yes, it would be very useful if shedskin could work with/output 64-bit numbers..
maybe I should have used 'long' everywhere instead of 'int'..! more generally, 
we'd
like to be able to configure the output for Python 'int' and 'float' types. 
problem
is, all the code in lib/ is now hardcoded to int/float, and would have to be 
changed
to use some #typedef in lib/builtin.hpp.. 

Original comment by mark.duf...@gmail.com on 30 Aug 2009 at 2:03

GoogleCodeExporter commented 8 years ago
This patch gives a speedup of 4% running. It avoids much functioncalls of 
getgx, with
making getgx local with "ggx = getgx()" and use ggx. This avoids 237395 getgx() 
calls
and saves (here in "my" testcase) 4%.

I thought it would be the best to test against the mandelbrot.py examle.

What's your opinion towarts this?

Original comment by thomas.s...@gmail.com on 8 Sep 2009 at 10:03

Attachments:

GoogleCodeExporter commented 8 years ago
arr, sorry for missing this patch!

I just tested it with examples/go.py, and got a 1% improvement. I'm sure for 
smaller
examples this will be more. I committed the patch to SVN. thanks!!

Original comment by mark.duf...@gmail.com on 14 Nov 2009 at 12:31

GoogleCodeExporter commented 8 years ago

Original comment by mark.duf...@gmail.com on 17 Mar 2010 at 8:40

GoogleCodeExporter commented 8 years ago

Original comment by mark.duf...@gmail.com on 21 Mar 2010 at 2:33

GoogleCodeExporter commented 8 years ago

Original comment by mark.duf...@gmail.com on 5 Oct 2010 at 2:05

GoogleCodeExporter commented 8 years ago
I guess we can close this. patches were committed, and shedskin itself is not 
really supported by shedskin, nor will it ever be. perhaps we could compile the 
type analysis separately, but I don't think that would be a good investment of 
time anytime soon.

Original comment by mark.duf...@gmail.com on 27 Oct 2010 at 1:38