Apologies for spamming the list.. Since the patch could not be applied 100%, I assume thats why I don't see any difference. Do I need to aply any others? In a specific order?
Dan. 2009/1/9 Daniel Kersten <[email protected]>: > I don't think it worked. Theres no real difference when running > pybench and my own code runs the same as before. Pity. (PS: this is > with the svn version of python) > > 2009/1/9 Daniel Kersten <[email protected]>: >> Ok, part of the patch failed, but I reapplied it and it builds now. I >> think I applied it BEFORE running ./configure, so the Makefile was >> wrong. At least, I guess that was the problem. >> >> Now, I guess I need to benchmark to see if it worked regardless of the >> patching errors.. >> >> Thanks for the help though!! >> >> Dan. >> >> 2009/1/9 Daniel Kersten <[email protected]>: >>> Ok, tried applying patch to both 2.6.1 and svn versions: >>> >>> dan-desktop ~/Desktop/python/release26-maint: patch -p1 < >>> threadedceval5.patch >>> patching file Makefile.pre.in >>> Hunk #1 succeeded at 248 (offset 1 line). >>> Hunk #2 succeeded at 578 with fuzz 2 (offset 4 lines). >>> patching file Python/ceval.c >>> Hunk #1 succeeded at 578 (offset -3 lines). >>> Hunk #2 succeeded at 752 (offset -2 lines). >>> Hunk #3 succeeded at 1061 (offset -71 lines). >>> Hunk #4 succeeded at 1119 (offset -71 lines). >>> Hunk #5 succeeded at 1136 (offset -71 lines). >>> Hunk #6 FAILED at 1148. >>> Hunk #7 FAILED at 1263. >>> Hunk #8 FAILED at 1424. >>> ... <more text> >>> 15 out of 50 hunks FAILED -- saving rejects to file Python/ceval.c.rej >>> patching file Python/makeopcodetargets.py >>> patching file Python/opcode_targets.h >>> >>> >>> Also, the script Python/makeopcodetargets.py exists and runs fine >>> (generates the file Python/opcode_targets.h), but some of the >>> generated opcodes STILL give "undefined" errors. >>> Since it uses a gcc specific extension, perhaps it is not recognizing >>> the labels as constants? Though, I assume the patch would enable it >>> and I AM using gcc after all. >>> >>> >>> 2009/1/8 Padraig Kitterick <[email protected]>: >>>> >>>> You want: >>>> >>>> patch -p1 < threadedceval5.patch >>>> >>>> Padraig >>>> >>>> Daniel Kersten wrote: >>>>> Hrm, thats strange.. it SAYS it was applied correctly.. i think.. >>>>> >>>>> 2009/1/8 Padraig Kitterick <[email protected]>: >>>>> >>>>>> That script is created by the patch, so if you don't see it then the >>>>>> patch hasn't applied correctly. >>>>>> >>>>>> Daniel Kersten wrote: >>>>>> >>>>>>> I did something like: patch -p1 Makefile < threadedceval5.patch >>>>>>> Also, I don't have that script. Where do I get it, I don't see it >>>>>>> anywhere. >>>>>>> >>>>>>> It makes sense that they would have used the svn version - I used >>>>>>> 2.6.1 sources found on the python.org download page. I'll try the svn >>>>>>> version tomorrow and see. >>>>>>> >>>>>>> >>>>>>> 2009/1/8 Michael Twomey <[email protected]>: >>>>>>> >>>>>>> >>>>>>>> Also, off the top of my head, I bet these are patches against svn, >>>>>>>> which probably means to need to run autoconf & co to regenerate >>>>>>>> configure and the makefiles. >>>>>>>> >>>>>>>> mick >>>>>>>> >>>>>>>> On Thu, Jan 8, 2009 at 17:11, Padraig Kitterick >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Those labels that are undefined should be generated as part of the >>>>>>>>> make >>>>>>>>> rules that the patch inserts ($(srcdir)/Python/makeopcodetargets.py). >>>>>>>>> How did you apply the patch? >>>>>>>>> >>>>>>>>> Daniel Kersten wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi again, >>>>>>>>>> >>>>>>>>>> Has anyone got any experience applying the threaded code patch to >>>>>>>>>> Python 2.6? >>>>>>>>>> http://bugs.python.org/issue4753 >>>>>>>>>> >>>>>>>>>> Apparently it changes the eval loop to uses threaded code instead of >>>>>>>>>> table lookups or something like that and can make the interpreter >>>>>>>>>> execute 10-20% faster on most platforms. Only works in gcc because it >>>>>>>>>> requires gcc's labels as values extension. >>>>>>>>>> >>>>>>>>>> Anyway, I'm trying to get this working and have applied the >>>>>>>>>> threadedceval5.patch patch. I don't really know much about >>>>>>>>>> diff/patch, >>>>>>>>>> so maybe I'm doing it wrong.. I'm not sure if I need the other files >>>>>>>>>> or what. The patch seems to have worked fine, but when compiling >>>>>>>>>> Python (2.6.1) I get this error: >>>>>>>>>> >>>>>>>>>> Python/ceval.c: In function 'PyEval_EvalFrameEx': >>>>>>>>>> Python/ceval.c:1057: error: '_Py_TracingPossible' undeclared (first >>>>>>>>>> use in this function) >>>>>>>>>> Python/ceval.c:1057: error: (Each undeclared identifier is reported >>>>>>>>>> only once >>>>>>>>>> Python/ceval.c:1057: error: for each function it appears in.) >>>>>>>>>> Python/opcode_targets.h:149: error: label 'TARGET_MAP_ADD' used but >>>>>>>>>> not defined >>>>>>>>>> Python/opcode_targets.h:148: error: label 'TARGET_SET_ADD' used but >>>>>>>>>> not defined >>>>>>>>>> Python/opcode_targets.h:147: error: label 'TARGET_LIST_APPEND' used >>>>>>>>>> but not defined >>>>>>>>>> Python/opcode_targets.h:136: error: label 'TARGET_MAKE_CLOSURE' used >>>>>>>>>> but not defined >>>>>>>>>> Python/opcode_targets.h:134: error: label 'TARGET_MAKE_FUNCTION' used >>>>>>>>>> but not defined >>>>>>>>>> Python/opcode_targets.h:132: error: label 'TARGET_RAISE_VARARGS' used >>>>>>>>>> but not defined >>>>>>>>>> >>>>>>>>>> followed by more undefined labels. >>>>>>>>>> Python/opcode_targets.h is just a big table of opcodes, the opcodes >>>>>>>>>> being the TARGET_* labels, but they don't seem to be defined any >>>>>>>>>> place. >>>>>>>>>> >>>>>>>>>> Has anyone successfully got this working? If yes, what am I doing >>>>>>>>>> wrong? >>>>>>>>>> >>>>>>>>>> Thanks!! >>>>>>>>>> Dan. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Daniel Kersten. >>> Leveraging dynamic paradigms since the synergies of 1985. >>> >> >> >> >> -- >> Daniel Kersten. >> Leveraging dynamic paradigms since the synergies of 1985. >> > > > > -- > Daniel Kersten. > Leveraging dynamic paradigms since the synergies of 1985. > -- Daniel Kersten. Leveraging dynamic paradigms since the synergies of 1985. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Python Ireland" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.ie/group/pythonireland?hl=en -~----------~----~----~----~------~----~------~--~---
