[realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
Hi again Ali, hope you had a nice festival weekend a week ago. Sielun Veljet... would have been nice to see them again after all these years. OK, I managed to make CAVE functionality work in Tundra 2.0, thanks a lot for the instructions. I've fiddled with the remake of the PythonScriptModule now and then, but I am just not up to it. It is just too full of references to the old modules and to the old way to define scenes and math. Errors after error... And I don't know how to to rewrite the code, even if I commented out all the compiler errors. Adding PythonQt to the deps seemed to work, though, by copying the PythonQt directory from NaaliDeps to Tundra2deps, and by adding the line 'configure_python_qt()' to the upper level CMakeLists.txt. At least vs2008 does not complain about '#include PythonQt.h'. Does anybody else need PythonScriptModule in Tundra2? I have to have it to make my own code work. I'd really appreciate it if any of you gurus would have the time to give me advice on how to port the PythonScriptModule to Tundra2. -- http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
Hi Ilikia, Sorry that I havent been more vocal here on the mailing list since getting back to work on monday. I have done some big efforts for the Tundra2 codebase since then. We are now working in the realXtend naali repo under tundra2 branch. I have made things build again like cave module. Python is still not done but I will get to it at some point. I would not use too much time for that yourself. I have enhanced our cmake system and how windows finds dependencies. I automated fetching deps so you dont have to do a manual svn checkout anymore, and no manual copying of files into /bin. Last night I made a make install step for Tundra2 that you can (later at least) pass a prefix and you can install your build there with /lib /bin /include stuff like normal. erno aka e` is working on the linux build for tundra2. Quick steps to get going 1. Clone Branch located at https://github.com/realXtend/naali/tree/tundra2 2. Have git.exe in your path and run win_update_deps_vs2008.bathttps://github.com/realXtend/naali/blob/tundra2/win_update_deps_vs2008.bat 3. Then run win_cmake_vs2008.bathttps://github.com/realXtend/naali/blob/tundra2/win_cmake_vs2008.bat as usual You don't anymore need to have TUNDRA_DEP_PATH or similar in your system env variables. The scripst will take care you have the latest deps, copy them to bin for you and when you run cmake the deps path is cached so you never have to pass it again (unless you really want to change it). If you want to forget the dep path + all the found deps ofc you can delete CMakeCache.txt. win_update_deps_*.bat does this for you so you wont get strange results after updating deps. Source code has been moved under /src and there is some subdir separations SDK vs application level. This structure is not final but prepares us for the future and makes us look like a proper project with an actual src dir ;) I made static libs build under /lib. I modified the cmake system quite much to make it nicer and adding cmake/TundraInstall.cmake for make install macros (for all platform, on visual studio right click INSTALL project and select Build!). I'll keep you posted on python (at least i promise to try and remember :). The situation there is that we need to remove a lot of dead code. How SDK gets exposed to .py code and so forth probably stays as is and is not really hard to make build. Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 3:24 PM, ilikia t...@ee.oulu.fi wrote: Hi again Ali, hope you had a nice festival weekend a week ago. Sielun Veljet... would have been nice to see them again after all these years. OK, I managed to make CAVE functionality work in Tundra 2.0, thanks a lot for the instructions. I've fiddled with the remake of the PythonScriptModule now and then, but I am just not up to it. It is just too full of references to the old modules and to the old way to define scenes and math. Errors after error... And I don't know how to to rewrite the code, even if I commented out all the compiler errors. Adding PythonQt to the deps seemed to work, though, by copying the PythonQt directory from NaaliDeps to Tundra2deps, and by adding the line 'configure_python_qt()' to the upper level CMakeLists.txt. At least vs2008 does not complain about '#include PythonQt.h'. Does anybody else need PythonScriptModule in Tundra2? I have to have it to make my own code work. I'd really appreciate it if any of you gurus would have the time to give me advice on how to port the PythonScriptModule to Tundra2. -- http://groups.google.com/group/realxtend http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
ilikia, Festivals - a great opportunity to miss bands... But to the business: you can delete Vector3dfDecorator.hcpp, QuaternionDecorator.hcpp and TransformDecorator.hcpp + all references to those files. That should help a bit at least. Grey skies, Ali Kämäräinen -- http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
How are the new math lib classes exposed to py? I did see that there were generated converter functions spesificly for the QScriptEngine. Are they QObjects? I mean if not we still need to make Qt based Decorators like that to feed them into PythonQt. At least i think so. I am under the impression that you need to feed qobject classes to the PythonQt. But I might actually be wrong, will have to ask toni next week when I see him. Either way, yah I'm cleaning out the module quite a bit. File and source wise, its in quite bad shape. The maintainers have been just commenting completely dead code for a long time so its a freaking mess :I I'll try to get it closer to our standards but not into fulling state today. Need to expose the math lib somehow at some point. At least things that get exposed over from EC_Placeable so its usable from py. Ali any comments on moving stuff under /src? I'd like to hear your ideas about how to structure the sources to get this SDK vs. application layers going. I think its already quite nice. My next big move would be to remove /bin from the repo all together and make it generate itself during the build. Moving all the data that is there currently will be quite easy to move under /src/ where the corresponding project is. As I did with my cmake install support thingie with the macros: https://github.com/realXtend/naali/commit/b528d36d13a61d39ecb6eb14c27e93f6319a81f8 Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 5:43 PM, Ali Kämäräinen stinkfi...@gmail.comwrote: ilikia, Festivals - a great opportunity to miss bands... But to the business: you can delete Vector3dfDecorator.hcpp, QuaternionDecorator.hcpp and TransformDecorator.hcpp + all references to those files. That should help a bit at least. Grey skies, Ali Kämäräinen -- http://groups.google.com/group/realxtend http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
The new math classes are not currently exposed to Python. The math classes are not QObjects, nor will be afaik. The QScriptBindings bindings generator (found in JavascriptModule) can be probably extended to generate Python bindings too. Whether they will be done using the decorator technique or not, I don't know atm. The shape of PythonScriptModule and bin/pymodules is horrible indeed, hear hear, and some major cleanup is needed. I haven't paid much attention to the stuff that you have been working on the tundra2-wip branch as I'm currently on my summer vacation, but what I've glanced, there seems to be some good stuff happening there. But if I were you, I wouldn't spend too much of a time yet fully restructuring the whole project on my own as no other Tundra developer party have been consulted in any way on the matter, nor any meetings (irl or irc) have been held. So my advice would to hold your horses a bit, and it to start working on this matter later in August. Grey skies, Ali Kämäräinen -- http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
Actually we have discussed this with Jukka from Ludo (and with Toni for many years moving sources to /src). What was discussed with Jukka before he left for summer holidays was the SDK vs. app level split being more strict. I have only done initial steps to do this separations. And I acknowledge that after everyone gets back things might still change, so its been on my mind. The idea Jukka had was to move the application layer to a different repo, that would then be fetched as a git submodule on top of the SDK, or even just pointing TUNDRA_SDK_ROOT to the app layer build system (this would be optimal imo). And the work I have been doing now supports all those possibilities once we decide something concrete. P.S Yeah dont spend too much on code, have a nice holiday ;) Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 6:44 PM, Ali Kämäräinen stinkfi...@gmail.comwrote: The new math classes are not currently exposed to Python. The math classes are not QObjects, nor will be afaik. The QScriptBindings bindings generator (found in JavascriptModule) can be probably extended to generate Python bindings too. Whether they will be done using the decorator technique or not, I don't know atm. The shape of PythonScriptModule and bin/pymodules is horrible indeed, hear hear, and some major cleanup is needed. I haven't paid much attention to the stuff that you have been working on the tundra2-wip branch as I'm currently on my summer vacation, but what I've glanced, there seems to be some good stuff happening there. But if I were you, I wouldn't spend too much of a time yet fully restructuring the whole project on my own as no other Tundra developer party have been consulted in any way on the matter, nor any meetings (irl or irc) have been held. So my advice would to hold your horses a bit, and it to start working on this matter later in August. Grey skies, Ali Kämäräinen -- http://groups.google.com/group/realxtend http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
Alright Ilikia I committed my stuff https://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e04f2c8db13348 https://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e04f2c8db13348Please do read the commit msg and understand i did not test this yet. You may do that if you check out our tundra2 branch like instructed earlier. I don't have time to test and finalize it now :) But it builds now. One thing I changed is the python '_naali' import to '_tundra'. So we need to make tundra.py that does the equivalent things as naali.py before (provides all the nice funcs and APIs). Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 8:08 PM, Jonne Nauha jo...@adminotech.com wrote: Actually we have discussed this with Jukka from Ludo (and with Toni for many years moving sources to /src). What was discussed with Jukka before he left for summer holidays was the SDK vs. app level split being more strict. I have only done initial steps to do this separations. And I acknowledge that after everyone gets back things might still change, so its been on my mind. The idea Jukka had was to move the application layer to a different repo, that would then be fetched as a git submodule on top of the SDK, or even just pointing TUNDRA_SDK_ROOT to the app layer build system (this would be optimal imo). And the work I have been doing now supports all those possibilities once we decide something concrete. P.S Yeah dont spend too much on code, have a nice holiday ;) Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 6:44 PM, Ali Kämäräinen stinkfi...@gmail.comwrote: The new math classes are not currently exposed to Python. The math classes are not QObjects, nor will be afaik. The QScriptBindings bindings generator (found in JavascriptModule) can be probably extended to generate Python bindings too. Whether they will be done using the decorator technique or not, I don't know atm. The shape of PythonScriptModule and bin/pymodules is horrible indeed, hear hear, and some major cleanup is needed. I haven't paid much attention to the stuff that you have been working on the tundra2-wip branch as I'm currently on my summer vacation, but what I've glanced, there seems to be some good stuff happening there. But if I were you, I wouldn't spend too much of a time yet fully restructuring the whole project on my own as no other Tundra developer party have been consulted in any way on the matter, nor any meetings (irl or irc) have been held. So my advice would to hold your horses a bit, and it to start working on this matter later in August. Grey skies, Ali Kämäräinen -- http://groups.google.com/group/realxtend http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
[realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
Wow guys, you really had a brainstorm this afternoon. Probably interesting things to come. Ali: I had already commented out all the code in the files you mentioned, they did not cause errors. The big problems occurred with PythonScriptModule and PythonScriptInstance, because they refer a lot to stuff like Scene::Entity etc., and Scene is defined very differently now. Is 1.* going to be terminated completely now? Or developed in parallel? Of course I can use the versions I've compiled so far as a backup, but I think that there are others who have built a lot on 1.*, like people at the CIE that I visited a couple of months ago. Anyway, I'll wait for the official release then. Maybe someone else will need PythonScriptModule, too, and the project will advance. Have a nice holiday guys. On Jul 22, 8:08 pm, Jonne Nauha jo...@adminotech.com wrote: Actually we have discussed this with Jukka from Ludo (and with Toni for many years moving sources to /src). What was discussed with Jukka before he left for summer holidays was the SDK vs. app level split being more strict. I have only done initial steps to do this separations. And I acknowledge that after everyone gets back things might still change, so its been on my mind. The idea Jukka had was to move the application layer to a different repo, that would then be fetched as a git submodule on top of the SDK, or even just pointing TUNDRA_SDK_ROOT to the app layer build system (this would be optimal imo). And the work I have been doing now supports all those possibilities once we decide something concrete. P.S Yeah dont spend too much on code, have a nice holiday ;) Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 6:44 PM, Ali Kämäräinen stinkfi...@gmail.comwrote: The new math classes are not currently exposed to Python. The math classes are not QObjects, nor will be afaik. The QScriptBindings bindings generator (found in JavascriptModule) can be probably extended to generate Python bindings too. Whether they will be done using the decorator technique or not, I don't know atm. The shape of PythonScriptModule and bin/pymodules is horrible indeed, hear hear, and some major cleanup is needed. I haven't paid much attention to the stuff that you have been working on the tundra2-wip branch as I'm currently on my summer vacation, but what I've glanced, there seems to be some good stuff happening there. But if I were you, I wouldn't spend too much of a time yet fully restructuring the whole project on my own as no other Tundra developer party have been consulted in any way on the matter, nor any meetings (irl or irc) have been held. So my advice would to hold your horses a bit, and it to start working on this matter later in August. Grey skies, Ali Kämäräinen -- http://groups.google.com/group/realxtend http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
[realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
Thanks again, I'll look at it next week. Might even try to think about what kinds of methods the new tundra.py module would need. On Jul 22, 9:25 pm, Jonne Nauha jo...@adminotech.com wrote: Alright Ilikia I committed my stuffhttps://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e... https://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e...Please do read the commit msg and understand i did not test this yet. You may do that if you check out our tundra2 branch like instructed earlier. I don't have time to test and finalize it now :) But it builds now. One thing I changed is the python '_naali' import to '_tundra'. So we need to make tundra.py that does the equivalent things as naali.py before (provides all the nice funcs and APIs). Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 8:08 PM, Jonne Nauha jo...@adminotech.com wrote: Actually we have discussed this with Jukka from Ludo (and with Toni for many years moving sources to /src). What was discussed with Jukka before he left for summer holidays was the SDK vs. app level split being more strict. I have only done initial steps to do this separations. And I acknowledge that after everyone gets back things might still change, so its been on my mind. The idea Jukka had was to move the application layer to a different repo, that would then be fetched as a git submodule on top of the SDK, or even just pointing TUNDRA_SDK_ROOT to the app layer build system (this would be optimal imo). And the work I have been doing now supports all those possibilities once we decide something concrete. P.S Yeah dont spend too much on code, have a nice holiday ;) Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 6:44 PM, Ali Kämäräinen stinkfi...@gmail.comwrote: The new math classes are not currently exposed to Python. The math classes are not QObjects, nor will be afaik. The QScriptBindings bindings generator (found in JavascriptModule) can be probably extended to generate Python bindings too. Whether they will be done using the decorator technique or not, I don't know atm. The shape of PythonScriptModule and bin/pymodules is horrible indeed, hear hear, and some major cleanup is needed. I haven't paid much attention to the stuff that you have been working on the tundra2-wip branch as I'm currently on my summer vacation, but what I've glanced, there seems to be some good stuff happening there. But if I were you, I wouldn't spend too much of a time yet fully restructuring the whole project on my own as no other Tundra developer party have been consulted in any way on the matter, nor any meetings (irl or irc) have been held. So my advice would to hold your horses a bit, and it to start working on this matter later in August. Grey skies, Ali Kämäräinen -- http://groups.google.com/group/realxtend http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
That would be helpful if you can give concrete use cases. But I recon youll do mighty well if we just expose all the SDK APIs and the full chain of scene - entity - component - attribute. The problem with the old python module is that there are all kinds of special getters and setter and own magic how to access things. We must fix this and make it similar to C++ and JavaScript, all languages should access things in Tundra with same calls to framework objects/APIs. Tundra 2.0 is just a name/version, it could be as well Tundra 1.1 or 1.5. It just means we are making big changes, just look at the version number. Meaning that when you start working with the 2.0 SDK you should already know that you might need to port some code lines to newer calls etc. :) I can't say for everyone but we at Adminotech want to move to 2.0 full time, we think its a step in the right direction. So far what I have seen, 2.0 brings alot of nice new features, polishes the code that was already there, removes years of legacy code and cruft that we really don't need. I am confident once people get to see the new stuff they will be happy to move along. The advantages for developers are huge, easier code base to work all around. So when Qt releases 4.8 I don't think anyone there still works on 4.7 or 4.6 versions of the code base, so I dont see a reason for us to do so either :) CIE has their own c++ code and scripts, and I actually visited there yesterday. But with the talks I have had with them they want to move to the new stuff when their timetables allows it. I/we need to properly first port existing code into 2.0 and have a solid working build on linux before they can jump along. But knowing the guys there and the code they are working with, this will be a trivial max day per module port. It took me 10 minutes on some modules to have a working 2.0 plugin from old module code :P I can tell everyone aswell that the dreaded code port from tundra to tundra 2.0 is very very simple and minimal work for the benefits you will actually enjoy once its done. I haven't ported JavaScript or python yet, but I cannot see more than search and replace stuff and some minor things with the new math lib that you will need to learn. So I encourage people not to fear this jump too much even if the talks were controversial here at some point. I might have been the most afraid how much our company code will have to be changed, but now I see no problems :) If you have probs please use the mailing lists, we are here to help. Long live 2.0! P.S. But as you said propably good to wait for our first rex release, we will do that once we get things sorted out. That might take some weeks though as everyone is on holiday and I cant make decisions alone even if I am the windows release master. Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 9:46 PM, ilikia t...@ee.oulu.fi wrote: Thanks again, I'll look at it next week. Might even try to think about what kinds of methods the new tundra.py module would need. On Jul 22, 9:25 pm, Jonne Nauha jo...@adminotech.com wrote: Alright Ilikia I committed my stuffhttps:// github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e... https://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e.. .Please do read the commit msg and understand i did not test this yet. You may do that if you check out our tundra2 branch like instructed earlier. I don't have time to test and finalize it now :) But it builds now. One thing I changed is the python '_naali' import to '_tundra'. So we need to make tundra.py that does the equivalent things as naali.py before (provides all the nice funcs and APIs). Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 8:08 PM, Jonne Nauha jo...@adminotech.com wrote: Actually we have discussed this with Jukka from Ludo (and with Toni for many years moving sources to /src). What was discussed with Jukka before he left for summer holidays was the SDK vs. app level split being more strict. I have only done initial steps to do this separations. And I acknowledge that after everyone gets back things might still change, so its been on my mind. The idea Jukka had was to move the application layer to a different repo, that would then be fetched as a git submodule on top of the SDK, or even just pointing TUNDRA_SDK_ROOT to the app layer build system (this would be optimal imo). And the work I have been doing now supports all those possibilities once we decide something concrete. P.S Yeah dont spend too much on code, have a nice holiday ;) Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 6:44 PM, Ali Kämäräinen stinkfi...@gmail.com wrote: The new math classes are not currently exposed to Python. The math classes are not QObjects, nor will be afaik. The QScriptBindings bindings generator (found in JavascriptModule)
Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!
I did some more work for python https://github.com/realXtend/naali/commit/b2a25515c384e53bd5c6382bec541711edd2948c New tundra.py that you import and use the core APIs: https://github.com/realXtend/naali/blob/tundra2/bin/pyplugins/tundra.py New apitests.py that you can run using Tundra.exe --pythonapitests to verify everything works: https://github.com/realXtend/naali/blob/tundra2/bin/pyplugins/lib/apitests.py I'm quite pleased how clean I got the main PythonScriptModule.cpp https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/PythonScriptModule.cpp Gutted it from almost 3000 lines into 600. The python side is now missing the modulemanager.py implementation (the circuits one), but that seemed to be full of legacy things as well. I think we will see how we implement that in the new things. I guess many people liked doing those Circuits.Component or did they? I mean now that we have the FrameAPI you can get frame updates without the whole modulemanager/circuits doing it for us. I think it could be enough if we just implemented a thing that loads startup .py plugins just like the js ones are defined now aswell in the startup config (see here https://github.com/realXtend/naali/blob/tundra2/bin/viewer.xml) Imo we should just make python script loading with the same system and forget all the rest. We will see what toni thinks when he gets back from holiday. Todo for PythonScriptModule: - .py plugin load system on startup - Expose new math lib to python (at least what EC_Mesh, EC_Placeable etc require for full functionality). - Possibly make a system for exposing classes outside PythonModule to PythonQt so that it does not have to link to everything. I'm not really sure how this can be done. Either PythonModule needs to link to everything vital or other stuff needs to link to PythonQt or something. I guess the first option is much better. Best regards, Jonne Nauha Adminotech developer On Sat, Jul 23, 2011 at 12:00 AM, Jonne Nauha jo...@adminotech.com wrote: That would be helpful if you can give concrete use cases. But I recon youll do mighty well if we just expose all the SDK APIs and the full chain of scene - entity - component - attribute. The problem with the old python module is that there are all kinds of special getters and setter and own magic how to access things. We must fix this and make it similar to C++ and JavaScript, all languages should access things in Tundra with same calls to framework objects/APIs. Tundra 2.0 is just a name/version, it could be as well Tundra 1.1 or 1.5. It just means we are making big changes, just look at the version number. Meaning that when you start working with the 2.0 SDK you should already know that you might need to port some code lines to newer calls etc. :) I can't say for everyone but we at Adminotech want to move to 2.0 full time, we think its a step in the right direction. So far what I have seen, 2.0 brings alot of nice new features, polishes the code that was already there, removes years of legacy code and cruft that we really don't need. I am confident once people get to see the new stuff they will be happy to move along. The advantages for developers are huge, easier code base to work all around. So when Qt releases 4.8 I don't think anyone there still works on 4.7 or 4.6 versions of the code base, so I dont see a reason for us to do so either :) CIE has their own c++ code and scripts, and I actually visited there yesterday. But with the talks I have had with them they want to move to the new stuff when their timetables allows it. I/we need to properly first port existing code into 2.0 and have a solid working build on linux before they can jump along. But knowing the guys there and the code they are working with, this will be a trivial max day per module port. It took me 10 minutes on some modules to have a working 2.0 plugin from old module code :P I can tell everyone aswell that the dreaded code port from tundra to tundra 2.0 is very very simple and minimal work for the benefits you will actually enjoy once its done. I haven't ported JavaScript or python yet, but I cannot see more than search and replace stuff and some minor things with the new math lib that you will need to learn. So I encourage people not to fear this jump too much even if the talks were controversial here at some point. I might have been the most afraid how much our company code will have to be changed, but now I see no problems :) If you have probs please use the mailing lists, we are here to help. Long live 2.0! P.S. But as you said propably good to wait for our first rex release, we will do that once we get things sorted out. That might take some weeks though as everyone is on holiday and I cant make decisions alone even if I am the windows release master. Best regards, Jonne Nauha Adminotech developer On Fri, Jul 22, 2011 at 9:46 PM, ilikia t...@ee.oulu.fi wrote:
