Open GoogleCodeExporter opened 8 years ago
thanks for reporting. could you please send me the sourcecode, possibly in
private, so it's much easier to have a look? :-)
Original comment by mark.duf...@gmail.com
on 6 Mar 2014 at 10:09
Ok so the fix here is:
/usr/lib/python2.7/dist-packages/shedskin/typestr.py:191
if set(lcp) == set([python.def_class(gx, 'int_'), python.def_class(gx, 'float_')]):
return conv['float_']
elif not node or not infer.inode(gx, node).mv or infer.inode(gx, node).mv.module.builtin:
Afterwards I get a list of types that are marked as "expression has dynamic"
I'll fix my code with displayed warnings and keep you updated.
I get that it's easier to have a look with the python sourcecode. My problem is
that his code is developed under a NDA with a thirdparty company. So I can't
provide it until you sign the NDA as well :)
Legals will definitely lead us to a sad end !
Cheers,
Olivier
Original comment by laetitia...@gmail.com
on 6 Mar 2014 at 10:52
the real problem is not here, but I guess not crashing here is a definite
improvement ^^ will have a look at your patch and probably commit it later
today.
btw how many lines of code is your program, and how long does it take to
analyze?
Original comment by mark.duf...@gmail.com
on 6 Mar 2014 at 10:55
The program is composed of 2 files, one of 700 lines, the other of 2500 lines.
It takes approx 10-15 minutes to get to the warning list (Core2 L9400)
The type analysis is very long. But well it definitely performs as I required
and the execution time gain later is tremendeous (even compared to pypy).
Basically the program I write performs optimizations in assembly code for an
embedded platform before the final link pass.
Cheers,
Olivier
Original comment by laetitia...@gmail.com
on 6 Mar 2014 at 11:00
Well I just saw I used my wife's google acocunt to post that. I've already
reported a bug sometimes ago.
Original comment by akato...@gmail.com
on 6 Mar 2014 at 11:02
sounds like an interesting tool. please let me know when you run into other
problems or if I can help optimize the result. you've probably already seen the
standard optimization tips in the wiki documentation.
Original comment by mark.duf...@gmail.com
on 6 Mar 2014 at 11:08
I'm afraid I hadn't checked out how to optimize the conversion process as it's
definitely not a show stopper !
Original comment by akato...@gmail.com
on 6 Mar 2014 at 11:36
Ok, I finally have a valid conversion, so basically, the unsupported thing is
this:
map = {}
def function(self,arg1,arg2):
map["somestring"] = ["string1","string2",int(arg1),int(arg2),"string3"]
function(3,4)
map["somestring"][2] += map["somestring"][3]
or something alike. The unsupported part is the array of mixed type. when
replaced by a class, it works like a charm.
Cheers,
Olivier
Original comment by akato...@gmail.com
on 6 Mar 2014 at 1:06
once you applied above fix, did shedskin give you useful warnings that pointed
you to the problem..?
Original comment by mark.duf...@gmail.com
on 6 Mar 2014 at 1:56
oh sorry you already said you got 'dynamic type' warnings.
Original comment by mark.duf...@gmail.com
on 6 Mar 2014 at 1:57
No problem,
Yes after the fix, warnings were relevant. So I was able to find a solution,
the only tricky stuff was the array with mixed item type.
Original comment by akato...@gmail.com
on 6 Mar 2014 at 3:15
this line was already fixed in GIT, good.. :-)
https://gitorious.org/shedskin/mainline/commit/78b4ef969f3b321dcf7a0a43a4d86d114
de005b2
did the analysis get much faster after fixing the dynamic types?
Original comment by mark.duf...@gmail.com
on 7 Mar 2014 at 10:24
Original issue reported on code.google.com by
laetitia...@gmail.com
on 6 Mar 2014 at 10:02