digitalmars.D.learn - Source code of a method.
- TheFlyingFiddle (2/2) Oct 26 2013 Is there a way to extract the source code of a method at
- QAston (3/5) Oct 26 2013 Short and to the point answer: no.
- Gary Willoughby (3/5) Oct 26 2013 Nope. What do you need to do?
- TheFlyingFiddle (26/31) Oct 26 2013 I'm currently making an AOP framework. I use UDA's to handle
- Gary Willoughby (7/40) Oct 26 2013 I kind of did the same thing here in the Mockable mixin:
- TheFlyingFiddle (5/10) Oct 26 2013 Hmm i never considered inheritance actually...
- QAston (3/13) Oct 27 2013 You can use decorator the same way too.
- Gary Willoughby (2/17) Oct 27 2013 Can you provide a simple example please?
- QAston (8/9) Oct 27 2013 Just the same way you generate code for inheritance you can use
- TheFlyingFiddle (10/17) Oct 27 2013 Yes i know and that was what i was doing initially, however in
- Baz (14/16) Nov 04 2013 Yep, at least on win32. (tested in win7 32 with DEP set to "ON"
- Baz (2/18) Nov 04 2013 And also: flush the instruction cache too ^^
- Jacob Carlborg (4/17) Nov 04 2013 That can't work at compile time?
- Baz (6/31) Nov 04 2013 No it's only a run-time trick.
Is there a way to extract the source code of a method at compiletime?
Oct 26 2013
"QAston" <qaston gmail.com> On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:Is there a way to extract the source code of a method at compiletime?Short and to the point answer: no.
Oct 26 2013
On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:Is there a way to extract the source code of a method at compiletime?Nope. What do you need to do?
Oct 26 2013
On Saturday, 26 October 2013 at 19:04:09 UTC, Gary Willoughby wrote:On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:I'm currently making an AOP framework. I use UDA's to handle logging, exception handling ect. It looks something like this currently. class Foo : IFoo { Log("bar.txt") DLLException() void bar(...params...) { //dosomething } } unittest { alias TypeTuple!(LogWrapper, DLLExeWrapper, ...) wrappers; //Normal foo auto fooProto = new Foo(); //Wrapped foo having some nice extra functionallity for Foo.bar IFoo foo = new wrap!(Foo, IFoo, wrappers)(fooProto); } Currently the wrappped foo delegates to fooProto aswell as adding the functinallity specified by the UDA's. I basically wanted to remove the delegation. And just put the source code in the newly created foo specialisation.Is there a way to extract the source code of a method at compiletime?Nope. What do you need to do?
Oct 26 2013
On Saturday, 26 October 2013 at 20:38:14 UTC, TheFlyingFiddle wrote:On Saturday, 26 October 2013 at 19:04:09 UTC, Gary Willoughby wrote:I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:I'm currently making an AOP framework. I use UDA's to handle logging, exception handling ect. It looks something like this currently. class Foo : IFoo { Log("bar.txt") DLLException() void bar(...params...) { //dosomething } } unittest { alias TypeTuple!(LogWrapper, DLLExeWrapper, ...) wrappers; //Normal foo auto fooProto = new Foo(); //Wrapped foo having some nice extra functionallity for Foo.bar IFoo foo = new wrap!(Foo, IFoo, wrappers)(fooProto); } Currently the wrappped foo delegates to fooProto aswell as adding the functinallity specified by the UDA's. I basically wanted to remove the delegation. And just put the source code in the newly created foo specialisation.Is there a way to extract the source code of a method at compiletime?Nope. What do you need to do?
Oct 26 2013
I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.Hmm i never considered inheritance actually... (I'm to used to the decorator pattern i guess ^^, Normally i only inherit from interfaces and decorate) But now that you pointed it out it's a perfect fit! Thanks for the help.
Oct 26 2013
On Saturday, 26 October 2013 at 22:56:20 UTC, TheFlyingFiddle wrote:You can use decorator the same way too.I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.Hmm i never considered inheritance actually... (I'm to used to the decorator pattern i guess ^^, Normally i only inherit from interfaces and decorate) But now that you pointed it out it's a perfect fit! Thanks for the help.
Oct 27 2013
On Sunday, 27 October 2013 at 09:00:24 UTC, QAston wrote:On Saturday, 26 October 2013 at 22:56:20 UTC, TheFlyingFiddle wrote:Can you provide a simple example please?You can use decorator the same way too.I kind of did the same thing here in the Mockable mixin: https://github.com/nomad-software/dunit Instead of wrapping i simply extended the target class so i have access to 'super.bar()'. Then i can add the specialisation code and/or call the original method too.Hmm i never considered inheritance actually... (I'm to used to the decorator pattern i guess ^^, Normally i only inherit from interfaces and decorate) But now that you pointed it out it's a perfect fit! Thanks for the help.
Oct 27 2013
On Sunday, 27 October 2013 at 14:34:14 UTC, Gary Willoughby wrote:Can you provide a simple example please?Just the same way you generate code for inheritance you can use to generate code for composition. You just call <membername>.method instead of super.method. I don't know if anyone can call that a simple example, but it's all i have by hand: https://github.com/QAston/DMocks-revived/blob/master/dmocks/object_mock.d I use this technique to mock structs and final classes.
Oct 27 2013
Yes i know and that was what i was doing initially, however in this specific case its unessasary and provides a little more extra bagage then simply inheriting. You get two objects instead of one => More cache locality problems aswell as more potential garabage the garabage collector needs to keep track of. (is this relevant? You never know. If i create 10000+ objects this way it's kinda relevant) The main problem with this approach for me is that i can't make the classes i write final. It's not rly a hard thing to do but it breaks a force of habit.Hmm i never considered inheritance actually... (I'm to used to the decorator pattern i guess ^^, Normally i only inherit from interfaces and decorate) But now that you pointed it out it's a perfect fit! Thanks for the help.You can use decorator the same way too.
Oct 27 2013
On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:Is there a way to extract the source code of a method at compiletime?Yep, at least on win32. (tested in win7 32 with DEP set to "ON" for everything) http://dpaste.dzfl.pl/19c77eee It doesn't run on DPaste (linux x86_64) that's why I restrict the "yes" to my own local test (on win32). basically: - set memory mode for reading code and grab it. - transform. (in my example I patch a bool as return value). - set memory mode for writing and patch it with your "patched-grabed-code". - call new code. :)
Nov 04 2013
On Monday, 4 November 2013 at 15:09:38 UTC, Baz wrote:On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:And also: flush the instruction cache too ^^Is there a way to extract the source code of a method at compiletime?Yep, at least on win32. (tested in win7 32 with DEP set to "ON" for everything) http://dpaste.dzfl.pl/19c77eee It doesn't run on DPaste (linux x86_64) that's why I restrict the "yes" to my own local test (on win32). basically: - set memory mode for reading code and grab it. - transform. (in my example I patch a bool as return value). - set memory mode for writing and patch it with your "patched-grabed-code". - call new code. :)
Nov 04 2013
On 2013-11-04 16:09, Baz wrote:On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:That can't work at compile time? -- /Jacob CarlborgIs there a way to extract the source code of a method at compiletime?Yep, at least on win32. (tested in win7 32 with DEP set to "ON" for everything) http://dpaste.dzfl.pl/19c77eee It doesn't run on DPaste (linux x86_64) that's why I restrict the "yes" to my own local test (on win32). basically: - set memory mode for reading code and grab it. - transform. (in my example I patch a bool as return value). - set memory mode for writing and patch it with your "patched-grabed-code". - call new code. :)
Nov 04 2013
On Monday, 4 November 2013 at 16:42:42 UTC, Jacob Carlborg wrote:On 2013-11-04 16:09, Baz wrote:No it's only a run-time trick. interesting example: turn mad a cracker who makes static analysic of the code. Because the code disasm from the exe is different from the code executed at run-time...On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:That can't work at compile time?Is there a way to extract the source code of a method at compiletime?Yep, at least on win32. (tested in win7 32 with DEP set to "ON" for everything) http://dpaste.dzfl.pl/19c77eee It doesn't run on DPaste (linux x86_64) that's why I restrict the "yes" to my own local test (on win32). basically: - set memory mode for reading code and grab it. - transform. (in my example I patch a bool as return value). - set memory mode for writing and patch it with your "patched-grabed-code". - call new code. :)
Nov 04 2013
On Monday, 4 November 2013 at 18:00:17 UTC, Baz wrote:On Monday, 4 November 2013 at 16:42:42 UTC, Jacob Carlborg wrote:http://s22.postimg.org/w589e9oyp/Patcher_Win32.png you can clearly see that after "run-time" patching proc3 return false instead of true...actually it's a common crack...33C0 vs B001. But if you want to monkey the stuff you have enough space - nop it (90) - rewrite your function and patch the offsets... - put your calls for your start stop tracing stuffs - in the remaining nop field put your E8<address of copied code>... and as you have no manual control over inlining you'll get UB...On 2013-11-04 16:09, Baz wrote:No it's only a run-time trick. interesting example: turn mad a cracker who makes static analysic of the code. Because the code disasm from the exe is different from the code executed at run-time...On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:That can't work at compile time?Is there a way to extract the source code of a method at compiletime?Yep, at least on win32. (tested in win7 32 with DEP set to "ON" for everything) http://dpaste.dzfl.pl/19c77eee It doesn't run on DPaste (linux x86_64) that's why I restrict the "yes" to my own local test (on win32). basically: - set memory mode for reading code and grab it. - transform. (in my example I patch a bool as return value). - set memory mode for writing and patch it with your "patched-grabed-code". - call new code. :)
Nov 04 2013
On Monday, 4 November 2013 at 19:50:22 UTC, Baz wrote:On Monday, 4 November 2013 at 18:00:17 UTC, Baz wrote:But something that you'll get.IF you work for Canal you bad... You are the guy who has designed an awesome database. I make this, as a dev: http://www.hostingpics.net/viewer.php?id=290757TuEsNul.png adobe air...the shame, you are also a javascript expert I guess... php douche...On Monday, 4 November 2013 at 16:42:42 UTC, Jacob Carlborg wrote:http://s22.postimg.org/w589e9oyp/Patcher_Win32.png you can clearly see that after "run-time" patching proc3 return false instead of true...actually it's a common crack...33C0 vs B001. But if you want to monkey the stuff you have enough space - nop it (90) - rewrite your function and patch the offsets... - put your calls for your start stop tracing stuffs - in the remaining nop field put your E8<address of copied code>... and as you have no manual control over inlining you'll get UB...On 2013-11-04 16:09, Baz wrote:No it's only a run-time trick. interesting example: turn mad a cracker who makes static analysic of the code. Because the code disasm from the exe is different from the code executed at run-time...On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:That can't work at compile time?Is there a way to extract the source code of a method at compiletime?Yep, at least on win32. (tested in win7 32 with DEP set to "ON" for everything) http://dpaste.dzfl.pl/19c77eee It doesn't run on DPaste (linux x86_64) that's why I restrict the "yes" to my own local test (on win32). basically: - set memory mode for reading code and grab it. - transform. (in my example I patch a bool as return value). - set memory mode for writing and patch it with your "patched-grabed-code". - call new code. :)
Nov 07 2013
On Thursday, 7 November 2013 at 17:31:45 UTC, Baz wrote:On Monday, 4 November 2013 at 19:50:22 UTC, Baz wrote:Can I have a green card ? No ? that's not enough to work in the US or even at TelAviv ?On Monday, 4 November 2013 at 18:00:17 UTC, Baz wrote:But something that you'll get.IF you work for Canal you bad... You are the guy who has designed an awesome database. I make this, as a dev: http://www.hostingpics.net/viewer.php?id=290757TuEsNul.png adobe air...the shame, you are also a javascript expert I guess... php douche...On Monday, 4 November 2013 at 16:42:42 UTC, Jacob Carlborg wrote:http://s22.postimg.org/w589e9oyp/Patcher_Win32.png you can clearly see that after "run-time" patching proc3 return false instead of true...actually it's a common crack...33C0 vs B001. But if you want to monkey the stuff you have enough space - nop it (90) - rewrite your function and patch the offsets... - put your calls for your start stop tracing stuffs - in the remaining nop field put your E8<address of copied code>... and as you have no manual control over inlining you'll get UB...On 2013-11-04 16:09, Baz wrote:No it's only a run-time trick. interesting example: turn mad a cracker who makes static analysic of the code. Because the code disasm from the exe is different from the code executed at run-time...On Saturday, 26 October 2013 at 16:36:35 UTC, TheFlyingFiddle wrote:That can't work at compile time?Is there a way to extract the source code of a method at compiletime?Yep, at least on win32. (tested in win7 32 with DEP set to "ON" for everything) http://dpaste.dzfl.pl/19c77eee It doesn't run on DPaste (linux x86_64) that's why I restrict the "yes" to my own local test (on win32). basically: - set memory mode for reading code and grab it. - transform. (in my example I patch a bool as return value). - set memory mode for writing and patch it with your "patched-grabed-code". - call new code. :)
Nov 07 2013