Oberon Community Platform Forum
November 20, 2019, 08:28:53 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Code Injection Demo  (Read 18109 times)
soren renner
Global Moderator
Full Member
*****
Posts: 216



« on: February 09, 2008, 08:58:16 PM »

Suppose you want to play with Turing demo. You could find the code which specifies the rules of the system, modify it, compile the new module, free the old module (thus shutting down the simulation if it is running) and start your modified module. But there is another way.

Download and compile the attached modules, and open the files in PET. Start a Turing cellular automaton running in a window. Now inject the code from Turing1. Inject Turing2. Change the rules in Turing1, free it, and reinject it. Repeat.

Be careful not to free one of the injected modules without first injecting the other one!

Post your improvements in this thread:
     *Interesting rule pairs.
     *Module freeing code in the injection method.
     *Injectable display rules.


* Turing2.Mod (0.51 KB - downloaded 416 times.)
* TuringCoatWnd.Mod (4.76 KB - downloaded 411 times.)
* Turing1.Mod (0.52 KB - downloaded 428 times.)
Logged
staubesv
Administrator
Sr. Member
*****
Posts: 387



« Reply #1 on: February 10, 2008, 05:44:53 PM »

Again, a cool demo! Thanks!

I added some code that enables clean module freeing. Also, I changed the rules in TuringCoatWnd.Mod and Turing2.Mod.

Note: In the previous version of TuringCoatWnd.Mod, mesh1 was passed as parameter for rule 2 two times (mesh2 was not passed at all). Now, both mesh1 and mesh2 are passed as parameters, so even I haven't changed Turing1.Mod, it now looks different.

Interesting: Since the meshes are shared within all window instances, the number of window instances influences the results.

BTW: You need to be logged in to see the file attachements.

* Turing1.Mod (0.57 KB - downloaded 404 times.)
* Turing2.Mod (0.6 KB - downloaded 426 times.)
* TuringCoatWnd.Mod (5.21 KB - downloaded 410 times.)
« Last Edit: February 10, 2008, 08:59:34 PM by staubesv » Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #2 on: February 10, 2008, 09:50:30 PM »

Excellent work, staubesv. Really nice. How do you feel about realtime raytracing? Say, a Sierpinsiki cube flythrough or something like that?

Logged
staubesv
Administrator
Sr. Member
*****
Posts: 387



« Reply #3 on: February 10, 2008, 10:28:12 PM »

I like realtime raytracing but I don't know much about the theory/mathematics behind it.

By the way: Your realtime raytracer that does a Sierpinsiki cube flythrough (if I understood this correctly) is part of the 23.01.2008 release and also contained in the repository. This fact has not really been announced and there's no entry in the startmenu yet... Have you done more work on it?
Also, it maybe interesting for you that Felix Friedrich has recently checked-in a new version of the PACO compiler that extends the Active Oberon language to support "intuitive and efficient mathematical programming" (see http://www.jg.inf.ethz.ch/wiki/Fof/Compiler).
Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #4 on: February 11, 2008, 01:22:06 AM »

Yes, they included it, but not as a demo runnable from the demo menu. Yes, I always continue to work on the tracer ... sometimes more, sometimes less. It would be nice to be able to use repository control software to push tracer updates to a repository at ethz. But I can easily post the modules here with explanatory text. In fact I would like to do so. The code injection trick was actually a "loss leader" to tempt you into the showroom, as it were. The trick was originally invented for use in the tracer. By the way, do you see why I was a little surprised to find that it worked? One thinks of interpreted languages as allowing dynamic compilation -- not statically compiled languages. Perhaps that only shows one's naivete.
Logged
staubesv
Administrator
Sr. Member
*****
Posts: 387



« Reply #5 on: February 11, 2008, 09:03:09 AM »

Have a look at http://www.ocp.inf.ethz.ch/forum/index.php/topic,22.0.html for information about how to get your code into the AOS repository. For us (ethz), the preferred way would be using the OCP repository for which you can get R/W access, but if you prefer posting the files on the Merge Requests board, that's fine, too.

If you would like to present your software, we invite you to do so on the OCP wiki. You could create an own project page that provides information/documentation/downloads for your raytracer. That's actually the idea behind the 'Projects' category on our wiki (see http://www.ocp.inf.ethz.ch/wiki/Projects/Front). A project page can have its own sidebar (see http://www.ocp.inf.ethz.ch/wiki/ExampleProject/Front) which makes it look like a separate webpage. Editing this wiki is really no big deal and can be learned quickly. The preferred way for providing downloads is also the OCP repository, although is possible to down-/upload files to the wiki.
Logged
felix
Administrator
Newbie
*****
Posts: 17



WWW
« Reply #6 on: February 11, 2008, 09:16:01 AM »

Also, it maybe interesting for you that Felix Friedrich has recently checked-in a new version of the PACO compiler that extends the Active Oberon language to support "intuitive and efficient mathematical programming" (see http://www.jg.inf.ethz.ch/wiki/Fof/Compiler).
I am currently working on a Active Oberon Language Report including all about the new array types but it will need some more time as I am working on many different things at the moment including a lecture to hold this semester...
I'll put it online as soon as something halfway tangible is available.
Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #7 on: February 16, 2008, 09:47:58 PM »

New cool demo available!

Remote code injection with UDPChat application.


* UDPChatInjection_fixed.zip (17.51 KB - downloaded 385 times.)
« Last Edit: February 17, 2008, 08:31:52 AM by sage » Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #8 on: February 16, 2008, 10:26:31 PM »

Sage:
    SageUDPChatServer.Mod will not compile for me. the line

           password:= Base.Buf.....

gives an "incompatible assignment" error.
Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #9 on: February 17, 2008, 08:33:52 AM »

I had attached new archive with fixes in original post.
Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #10 on: February 17, 2008, 06:04:20 PM »

I don't understand how your demo works. How is the code injection used with the chat? I must be confused. In any case, the modified TuringCoatWnd.Mod is needed along with the two injectable modules, as the version present in the distro will not work with them -- they won't even compile.
Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #11 on: February 17, 2008, 09:17:34 PM »

I don't understand how your demo works. How is the code injection used with the chat? I must be confused. In any case, the modified TuringCoatWnd.Mod is needed along with the two injectable modules, as the version present in the distro will not work with them -- they won't even compile.

To see how it works:
1. Start the UDPChatServer application.
2. Start at least one UDPChatClient. There is an loopback network (localhost) interface must be present in system if client will start on the same PC.
3. Get new user ID and login in using that ID and password. If all works well there is an string(s) like "User with User ID: #XXXX now known as 'XXXX'" must appear in chat history.
4. Start TuringCoatWnd application (use latest release supplied here in topic by staubesv).
5. Type in field with ".Mod" name of some module to inject, "Turing1.Mod" for example. And then press the button "Send code".
To simplify control of loading/unloading of injectable modules I had changed "Turing1.Mod" and "Turing2.Mod" a little. Its file names are differ but MODULE XXXX; names are the equal to "TuringCoatInjection". This value is also hard-coded now in UDPChatClient application. Maybe better solution exists... Because it's very important to know what actually module need to be loaded/unloaded.
« Last Edit: February 17, 2008, 11:31:34 PM by sage » Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!