Closed GoogleCodeExporter closed 9 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
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
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
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:
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
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
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
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:
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
Original comment by mark.duf...@gmail.com
on 17 Mar 2010 at 8:40
Original comment by mark.duf...@gmail.com
on 21 Mar 2010 at 2:33
Original comment by mark.duf...@gmail.com
on 5 Oct 2010 at 2:05
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
Original issue reported on code.google.com by
thomas.s...@gmail.com
on 23 Aug 2009 at 5:26Attachments: