Thread: [Pyobjc-dev] Intel objc.inject?
Brought to you by:
ronaldoussoren
From: Zachary C. <za...@je...> - 2006-07-12 20:02:30
|
Hi, I was wondering what the status of the Intel objc.inject was. Was the code from: http://guiheneuf.org/mach%20inject%20for%20intel.html and http://guiheneuf.org/InjectionControl.html used? Thanks! --Zach |
From: Ronald O. <ron...@ma...> - 2006-07-12 20:15:11
|
On Jul 12, 2006, at 10:02 PM, Zachary Cimafonte wrote: > Hi, I was wondering what the status of the Intel objc.inject was. Was > the code from: > http://guiheneuf.org/mach%20inject%20for%20intel.html > and > http://guiheneuf.org/InjectionControl.html > used? Thanks! objc.inject isn't supported on intel. Patches are happily accepted, but I don't use objc.inject myself and don't have time to work on this. Ronald |
From: Bob I. <bo...@re...> - 2006-07-12 20:28:28
|
On Jul 12, 2006, at 1:14 PM, Ronald Oussoren wrote: > > On Jul 12, 2006, at 10:02 PM, Zachary Cimafonte wrote: > >> Hi, I was wondering what the status of the Intel objc.inject was. Was >> the code from: >> http://guiheneuf.org/mach%20inject%20for%20intel.html >> and >> http://guiheneuf.org/InjectionControl.html >> used? Thanks! > > objc.inject isn't supported on intel. Patches are happily accepted, > but I don't use objc.inject myself and don't have time to work on > this. Same here, all of my spare python time is going into py2app/ setuptools related stuff. objc.inject is a fun debugging/exploration tool, but it's not really useful for many legitimate purposes. -bob |
From: Bill B. <bb...@ap...> - 2006-07-13 00:39:35
|
On Jul 12, 2006, at 1:28 PM, Bob Ippolito wrote: > On Jul 12, 2006, at 1:14 PM, Ronald Oussoren wrote: >> On Jul 12, 2006, at 10:02 PM, Zachary Cimafonte wrote: >>> Hi, I was wondering what the status of the Intel objc.inject was. >>> Was >>> the code from: >>> http://guiheneuf.org/mach%20inject%20for%20intel.html >>> and >>> http://guiheneuf.org/InjectionControl.html >>> used? Thanks! >> >> objc.inject isn't supported on intel. Patches are happily accepted, >> but I don't use objc.inject myself and don't have time to work on >> this. > > Same here, all of my spare python time is going into py2app/ > setuptools related stuff. > > objc.inject is a fun debugging/exploration tool, but it's not really > useful for many legitimate purposes. I can do it after August 12th. Until then, I'm a bit busy. |
From: ytrewq1 <yt...@gm...> - 2006-07-13 06:48:46
|
On 7/13/06, Bill Bumgarner <bb...@ap...> wrote: > > I can do it after August 12th. Until then, I'm a bit busy. That sounds great! I hope what you're working on until then goes well :-) |
From: ytrewq1 <yt...@gm...> - 2006-08-25 05:07:48
|
Have you happened to have a chance to look at objc.inject for intel? On 7/13/06, ytrewq1 <yt...@gm...> wrote: > On 7/13/06, Bill Bumgarner <bb...@ap...> wrote: > > > > I can do it after August 12th. Until then, I'm a bit busy. > > That sounds great! > > I hope what you're working on until then goes well :-) |
From: Bill B. <bb...@ap...> - 2006-08-25 05:14:13
|
On Aug 24, 2006, at 10:07 PM, ytrewq1 wrote: > Have you happened to have a chance to look at objc.inject > for intel? Unfortunately, no, haven't had time. |
From: Dethe E. <de...@li...> - 2006-08-25 14:06:17
|
You can use InputManagers to get Python code running in an arbitrary Cocoa application. The easiest way to do this is with SIMBL, which is an InputManager designed to run plugins in specific applications (the plugin specifies the app(s)). You have to restart the application to load the InputManager (and plugin) rather than injecting into a running app, so it's not going to work for every usecase that objc.inject does, but depending on your needs it might work for you. There's an example on my weblog that adds a new menu item (and feature) to Safari: http://livingcode.org/entry/ tab_dumping_in_safari.html. I wouldn't mind this getting into the PyObjC examples directory (hint, hint). I hope this helps. --Dethe On 24-Aug-06, at 10:14 PM, Bill Bumgarner wrote: > On Aug 24, 2006, at 10:07 PM, ytrewq1 wrote: >> Have you happened to have a chance to look at objc.inject >> for intel? > > Unfortunately, no, haven't had time. > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev "...coding isn't the poor handmaiden of design or analysis. Coding is where your fuzzy, comfortable ideas awaken in the harsh dawn of reality. It is where you learn what your computer can do. If you stop coding, you stop learning." Kent Beck, Smalltalk Best Practice Patterns |
From: Dethe E. <de...@li...> - 2006-08-25 21:24:22
|
Excellent. I tried your setup and it worked a treat. Getting a python console in Safari was one of my next projects and you just saved me the trouble. This makes it a lot easier in the future to explore the API to find the methods needed. Thanks! --Dethe On 25-Aug-06, at 10:24 AM, ytrewq1 wrote: > On 8/26/06, Dethe Elza <de...@li...> wrote: >> On 25-Aug-06, at 9:08 AM, ytrewq1 wrote: >> >> > FWIW, I made some quick and dirty modifications to the >> > InjectInterpreter PyObjC sample to use it w/ SIMBL. >> >> Cool, is it working now? > > Yes, happily so :-) In case you wish to give it a try, I've attached > the slightly modified setup.py -- I just copied the InjectInterpreter > sample code to a different directory and used the replacement > setup.py to build an appropriate bundle (by default launching > Safari should also bring up a Python interpreter window from > which to experiment). > > Perhaps I'll try the class browser sample next. > >> > It's kind of a pain to have to edit the SIMBL plug-in's >> > Info.plist file to add info for each individual app I want to >> > inject an interpreter in, but at least it seems to work :-) >> >> Alternatively, you could use the source for SIMBL (it's open-source) >> as the basis for creating your own InputManager, which gets loaded >> into *every* Cocoa-based application at startup. If you want code >> that runs everywhere, that's the way to go. If you want to tell >> applications to load your code while they are running you can create >> an InputManager that simply listens for a trigger (signal, port, >> AppleEvent, whatever) that causes it to load some code and run it (I >> leave it to you to consider the security implications of such a >> thing). That would be kind of a pre-injection. > > Yes, this is certainly one approach. A poor person's approach > might be > to provide a convenient command to edit the Info.plist in the SIMBL > bundle. > I may just do this and provide a UI for the capability through > Quicksilver if > it turns out to be simple. > >> I don't know what is involved in getting objc.inject working on Intel >> to know which method is more work. > > I don't know either, but I don't get the feeling that it's trivial. > >> The pre-injection method is pretty straightforward, but is >> invasive to >> basically every program that you run, just in case you might want >> to inject >> code into it. On that basis, objc.inject is a better citizen. > > Indeed. I've been wondering though whether there is any difference > in stability. > > Thanks again for your tip! > <setup.py> "The infighting is so vicious because the stakes are so low." |
From: ytrewq1 <yt...@gm...> - 2006-08-26 02:14:51
|
Glad to hear it's working. All I did though was apply what you figured out to the very nice PyObjC InjectInterpreter example :-) BTW, I tried something similar w/ the class browser injection example. A similarly modified setup.py did the trick with one caveat -- I think removing the menu from the nib makes for a better experience. Perhaps the class browser injection demo can be updated to remove the menu -- I always wondered what happened to my target application's menu and now I think I understand. On 8/26/06, Dethe Elza <de...@li...> wrote: > Excellent. I tried your setup and it worked a treat. Getting a > python console in Safari was one of my next projects and you just > saved me the trouble. This makes it a lot easier in the future to > explore the API to find the methods needed. > > Thanks! > > --Dethe > > On 25-Aug-06, at 10:24 AM, ytrewq1 wrote: > > > On 8/26/06, Dethe Elza <de...@li...> wrote: > >> On 25-Aug-06, at 9:08 AM, ytrewq1 wrote: > >> > >> > FWIW, I made some quick and dirty modifications to the > >> > InjectInterpreter PyObjC sample to use it w/ SIMBL. > >> > >> Cool, is it working now? > > > > Yes, happily so :-) In case you wish to give it a try, I've attached > > the slightly modified setup.py -- I just copied the InjectInterpreter > > sample code to a different directory and used the replacement > > setup.py to build an appropriate bundle (by default launching > > Safari should also bring up a Python interpreter window from > > which to experiment). > > > > Perhaps I'll try the class browser sample next. > > > >> > It's kind of a pain to have to edit the SIMBL plug-in's > >> > Info.plist file to add info for each individual app I want to > >> > inject an interpreter in, but at least it seems to work :-) > >> > >> Alternatively, you could use the source for SIMBL (it's open-source) > >> as the basis for creating your own InputManager, which gets loaded > >> into *every* Cocoa-based application at startup. If you want code > >> that runs everywhere, that's the way to go. If you want to tell > >> applications to load your code while they are running you can create > >> an InputManager that simply listens for a trigger (signal, port, > >> AppleEvent, whatever) that causes it to load some code and run it (I > >> leave it to you to consider the security implications of such a > >> thing). That would be kind of a pre-injection. > > > > Yes, this is certainly one approach. A poor person's approach > > might be > > to provide a convenient command to edit the Info.plist in the SIMBL > > bundle. > > I may just do this and provide a UI for the capability through > > Quicksilver if > > it turns out to be simple. > > > >> I don't know what is involved in getting objc.inject working on Intel > >> to know which method is more work. > > > > I don't know either, but I don't get the feeling that it's trivial. > > > >> The pre-injection method is pretty straightforward, but is > >> invasive to > >> basically every program that you run, just in case you might want > >> to inject > >> code into it. On that basis, objc.inject is a better citizen. > > > > Indeed. I've been wondering though whether there is any difference > > in stability. > > > > Thanks again for your tip! > > <setup.py> > > > "The infighting is so vicious because the stakes are so low." |
From: Dethe E. <de...@li...> - 2006-08-26 13:32:06
|
In both examples, rather than create a menu from the nib, and rather than to start up automatically, it would probably be better to add a menu item programatically that starts up the interpreter/class browser. --Dethe On 25-Aug-06, at 7:14 PM, ytrewq1 wrote: > Glad to hear it's working. All I did though was apply what > you figured out to the very nice PyObjC InjectInterpreter > example :-) > > BTW, I tried something similar w/ the class browser injection > example. A similarly modified setup.py did the trick with one > caveat -- I think removing the menu from the nib makes for a > better experience. Perhaps the class browser injection demo > can be updated to remove the menu -- I always wondered what > happened to my target application's menu and now I think I > understand. > > On 8/26/06, Dethe Elza <de...@li...> wrote: >> Excellent. I tried your setup and it worked a treat. Getting a >> python console in Safari was one of my next projects and you just >> saved me the trouble. This makes it a lot easier in the future to >> explore the API to find the methods needed. >> >> Thanks! >> >> --Dethe >> >> On 25-Aug-06, at 10:24 AM, ytrewq1 wrote: >> >> > On 8/26/06, Dethe Elza <de...@li...> wrote: >> >> On 25-Aug-06, at 9:08 AM, ytrewq1 wrote: >> >> >> >> > FWIW, I made some quick and dirty modifications to the >> >> > InjectInterpreter PyObjC sample to use it w/ SIMBL. >> >> >> >> Cool, is it working now? >> > >> > Yes, happily so :-) In case you wish to give it a try, I've >> attached >> > the slightly modified setup.py -- I just copied the >> InjectInterpreter >> > sample code to a different directory and used the replacement >> > setup.py to build an appropriate bundle (by default launching >> > Safari should also bring up a Python interpreter window from >> > which to experiment). >> > >> > Perhaps I'll try the class browser sample next. >> > >> >> > It's kind of a pain to have to edit the SIMBL plug-in's >> >> > Info.plist file to add info for each individual app I want to >> >> > inject an interpreter in, but at least it seems to work :-) >> >> >> >> Alternatively, you could use the source for SIMBL (it's open- >> source) >> >> as the basis for creating your own InputManager, which gets loaded >> >> into *every* Cocoa-based application at startup. If you want code >> >> that runs everywhere, that's the way to go. If you want to tell >> >> applications to load your code while they are running you can >> create >> >> an InputManager that simply listens for a trigger (signal, port, >> >> AppleEvent, whatever) that causes it to load some code and run >> it (I >> >> leave it to you to consider the security implications of such a >> >> thing). That would be kind of a pre-injection. >> > >> > Yes, this is certainly one approach. A poor person's approach >> > might be >> > to provide a convenient command to edit the Info.plist in the SIMBL >> > bundle. >> > I may just do this and provide a UI for the capability through >> > Quicksilver if >> > it turns out to be simple. >> > >> >> I don't know what is involved in getting objc.inject working on >> Intel >> >> to know which method is more work. >> > >> > I don't know either, but I don't get the feeling that it's trivial. >> > >> >> The pre-injection method is pretty straightforward, but is >> >> invasive to >> >> basically every program that you run, just in case you might want >> >> to inject >> >> code into it. On that basis, objc.inject is a better citizen. >> > >> > Indeed. I've been wondering though whether there is any difference >> > in stability. >> > >> > Thanks again for your tip! >> > <setup.py> >> >> >> "The infighting is so vicious because the stakes are so low." "Say what you like about C++, but it's uninitialized variables will always hold a special place in my heart. In a world where we define *everything* concretely it is the last refuge of the undefined. It's the programmer's Wild West, the untamed frontier." --Bjorn Stroustrap |
From: ytrewq1 <yt...@gm...> - 2006-08-26 15:39:17
|
I'm not sure I quite follow what you mean, but FWIW: In the context of applying the modified examples w/ SIMBL, I agree with the sentiment of your suggestion -- perhaps a menu item is a good way to provide a 'trigger', though as a Quicksilver user, I'm tempted to provide a different means ;-) (BTW, I don't think the InjectInterpreter example does anything w/ menus currently -- I think it's just InjectBrowser). When the 2 Inject* examples are used via the test.py scripts (i,e, using objc.inject), I think they make sense the way they are now (except for the class browser having a menu). I interpret the current arrangement as execution of the test.py script implying that a user wants to see an interpreter or browser immediately -- if the user isn't ready for the interpreter or browser, execution of the script can just be delayed until the user is ready. On 8/26/06, Dethe Elza <de...@li...> wrote: > In both examples, rather than create a menu from the nib, and rather > than to start up automatically, it would probably be better to add a > menu item programatically that starts up the interpreter/class browser. > > --Dethe > > On 25-Aug-06, at 7:14 PM, ytrewq1 wrote: > > > Glad to hear it's working. All I did though was apply what > > you figured out to the very nice PyObjC InjectInterpreter > > example :-) > > > > BTW, I tried something similar w/ the class browser injection > > example. A similarly modified setup.py did the trick with one > > caveat -- I think removing the menu from the nib makes for a > > better experience. Perhaps the class browser injection demo > > can be updated to remove the menu -- I always wondered what > > happened to my target application's menu and now I think I > > understand. > > > > On 8/26/06, Dethe Elza <de...@li...> wrote: > >> Excellent. I tried your setup and it worked a treat. Getting a > >> python console in Safari was one of my next projects and you just > >> saved me the trouble. This makes it a lot easier in the future to > >> explore the API to find the methods needed. > >> > >> Thanks! > >> > >> --Dethe > >> > >> On 25-Aug-06, at 10:24 AM, ytrewq1 wrote: > >> > >> > On 8/26/06, Dethe Elza <de...@li...> wrote: > >> >> On 25-Aug-06, at 9:08 AM, ytrewq1 wrote: > >> >> > >> >> > FWIW, I made some quick and dirty modifications to the > >> >> > InjectInterpreter PyObjC sample to use it w/ SIMBL. > >> >> > >> >> Cool, is it working now? > >> > > >> > Yes, happily so :-) In case you wish to give it a try, I've > >> attached > >> > the slightly modified setup.py -- I just copied the > >> InjectInterpreter > >> > sample code to a different directory and used the replacement > >> > setup.py to build an appropriate bundle (by default launching > >> > Safari should also bring up a Python interpreter window from > >> > which to experiment). > >> > > >> > Perhaps I'll try the class browser sample next. > >> > > >> >> > It's kind of a pain to have to edit the SIMBL plug-in's > >> >> > Info.plist file to add info for each individual app I want to > >> >> > inject an interpreter in, but at least it seems to work :-) > >> >> > >> >> Alternatively, you could use the source for SIMBL (it's open- > >> source) > >> >> as the basis for creating your own InputManager, which gets loaded > >> >> into *every* Cocoa-based application at startup. If you want code > >> >> that runs everywhere, that's the way to go. If you want to tell > >> >> applications to load your code while they are running you can > >> create > >> >> an InputManager that simply listens for a trigger (signal, port, > >> >> AppleEvent, whatever) that causes it to load some code and run > >> it (I > >> >> leave it to you to consider the security implications of such a > >> >> thing). That would be kind of a pre-injection. > >> > > >> > Yes, this is certainly one approach. A poor person's approach > >> > might be > >> > to provide a convenient command to edit the Info.plist in the SIMBL > >> > bundle. > >> > I may just do this and provide a UI for the capability through > >> > Quicksilver if > >> > it turns out to be simple. > >> > > >> >> I don't know what is involved in getting objc.inject working on > >> Intel > >> >> to know which method is more work. > >> > > >> > I don't know either, but I don't get the feeling that it's trivial. > >> > > >> >> The pre-injection method is pretty straightforward, but is > >> >> invasive to > >> >> basically every program that you run, just in case you might want > >> >> to inject > >> >> code into it. On that basis, objc.inject is a better citizen. > >> > > >> > Indeed. I've been wondering though whether there is any difference > >> > in stability. > >> > > >> > Thanks again for your tip! > >> > <setup.py> > >> > >> > >> "The infighting is so vicious because the stakes are so low." > > > "Say what you like about C++, but it's uninitialized variables will > always > hold a special place in my heart. In a world where we define > *everything* > concretely it is the last refuge of the undefined. It's the programmer's > Wild West, the untamed frontier." --Bjorn Stroustrap > > > |