goya
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2011
12:27 PM
re: Roku / BrightScript Emulator
Are there any plans or is anyone working on Roku / BrightScript emulator?
If so, please let me know.
If no, arround 1996-1997 I created an open source scripting language named iScript in Java whose syntax is a close mix of basic and java and who should not be two hard to dumb down to be very close to BrightScript. The best thing about iScript is that it has nice IDE with full debugger.
Then it should not be too hard to create components libary in Java AWT/Swing to emulate the Roku player components and supporting libraries (API) and create iScript wrapper to make accessible using BrightScript like CreateObject().
So if there is no one working on it and if the powers that be don't object I can put something together in short order... It's basically dumb down the iScript syntax, remove all the object oriented stuff, all exception handling, a lot of the syntax sugar, sadly remove much of the language and a lot of hard work, and then some do some minor tweaks.
I guess I can do an BrightScript swith which limits the keywords that the lexical analyser recognizers and that limits the parser and also tweak the parser to handle the minor differences. For example iScript supports continue and break, but not exit for/exit while and while it internally support goto I do not expose it to it's users. So it should not be two hard to tweak the language.
The components and libraries can be also done in short order with some community envolvement over time. So if this gets enough blessing, I will be calling for unpaid volunteers...
The IDE should not be two hard to add package which creates a zip files with all the necessary content and deploy which would send it to some roku player.
So is anyone interested? Is it ok enough with Roku? Or do they have something better in the pipeline and I can go back to playing with my roku?
If so, please let me know.
If no, arround 1996-1997 I created an open source scripting language named iScript in Java whose syntax is a close mix of basic and java and who should not be two hard to dumb down to be very close to BrightScript. The best thing about iScript is that it has nice IDE with full debugger.
Then it should not be too hard to create components libary in Java AWT/Swing to emulate the Roku player components and supporting libraries (API) and create iScript wrapper to make accessible using BrightScript like CreateObject().
So if there is no one working on it and if the powers that be don't object I can put something together in short order... It's basically dumb down the iScript syntax, remove all the object oriented stuff, all exception handling, a lot of the syntax sugar, sadly remove much of the language and a lot of hard work, and then some do some minor tweaks.
I guess I can do an BrightScript swith which limits the keywords that the lexical analyser recognizers and that limits the parser and also tweak the parser to handle the minor differences. For example iScript supports continue and break, but not exit for/exit while and while it internally support goto I do not expose it to it's users. So it should not be two hard to tweak the language.
The components and libraries can be also done in short order with some community envolvement over time. So if this gets enough blessing, I will be calling for unpaid volunteers...
The IDE should not be two hard to add package which creates a zip files with all the necessary content and deploy which would send it to some roku player.
So is anyone interested? Is it ok enough with Roku? Or do they have something better in the pipeline and I can go back to playing with my roku?
6 REPLIES 6
goya
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2011
05:52 PM
Re: re: Roku / BrightScript Emulator
sad not a single reply 😞
well, i'm not good at taking hints.
So this weekend I've starting creating the Java classes and interfaces that will make up Roku Components, Interfaces and Events.
Now my thoughts is not to implement my own version of Roku device in Java, but to create something simple that I and others can use to more easily develop Roku applications (Channels and Screensavers).
I've based my work on past emulators that I have used such as those for smart phones, just a little less functional, but no less useful.
By that I mean that the components will basically not much more than mock objects to begin with that the developers can use with some command line and/or gui to monitor the state of the emulated device and to interact with the emulated device, in this case the Roku player and the program that they are running.
So just like on my smart phone emulator I can use the gui to make it look like there is an incoming phone call and the software running on the emulator will react just like there is an incoming phone call, but in all reality there is no incoming phone call.
And the same way that the software being runned on the emulator can make a phone call or do other things that result in nothing more taking place than it being returned what the develop indicated to the emulator. So I can in response to my smart phone software return line busy or some other valid outcome without making any phone call at all. Arent mock objects great!
Same will be for the Roku emulator. It will be able to ask for things from the mock components and what is returned or happens is based not on reality, but what the developer needs to test a section of code. So for example the software that is running can being playing a video and later on the emulator can return that the video ended or that the video was not found, ect but it's all fake, it was just how the developer and/or tester indicated, not that there was ever any video at all being played.
Anyways, I've been making good progress on creating stubs for the components. The next step is to finish some work I have to finish on around xml serialization and iScript and that will free me to be able to some not too distant weekend dumb down iScript to syntax level close to BrightScript.
Then I should be able to craft some magic to expose the Java components that I've been putting together in a manner simular to how they are accessed by BrightScript...
Then, I will need to do a little work to make iScript more like BrightScript, not too much work...
Then, I will need to cook up some Swing/AWT thingy that will be the emulator UI that the developer and or tester will use for example to say that the video has stopped playing...
Finally, I will need to change iBuild (the IDE) to be able to package and deploy to the Roku player and to bake package for distribution... So that the user can just press some button or select some menu item and not have to go to the Web interface, but that has lower priority.
Oh, one more thing, as soon as I have something, I'll post it for all...
cheers
when i do get something out I can use some help by people who are familiar with developing on Roku and the Roku Components and Language testing my work and maybe even getting involved in its development...
well, i'm not good at taking hints.
So this weekend I've starting creating the Java classes and interfaces that will make up Roku Components, Interfaces and Events.
Now my thoughts is not to implement my own version of Roku device in Java, but to create something simple that I and others can use to more easily develop Roku applications (Channels and Screensavers).
I've based my work on past emulators that I have used such as those for smart phones, just a little less functional, but no less useful.
By that I mean that the components will basically not much more than mock objects to begin with that the developers can use with some command line and/or gui to monitor the state of the emulated device and to interact with the emulated device, in this case the Roku player and the program that they are running.
So just like on my smart phone emulator I can use the gui to make it look like there is an incoming phone call and the software running on the emulator will react just like there is an incoming phone call, but in all reality there is no incoming phone call.
And the same way that the software being runned on the emulator can make a phone call or do other things that result in nothing more taking place than it being returned what the develop indicated to the emulator. So I can in response to my smart phone software return line busy or some other valid outcome without making any phone call at all. Arent mock objects great!
Same will be for the Roku emulator. It will be able to ask for things from the mock components and what is returned or happens is based not on reality, but what the developer needs to test a section of code. So for example the software that is running can being playing a video and later on the emulator can return that the video ended or that the video was not found, ect but it's all fake, it was just how the developer and/or tester indicated, not that there was ever any video at all being played.
Anyways, I've been making good progress on creating stubs for the components. The next step is to finish some work I have to finish on around xml serialization and iScript and that will free me to be able to some not too distant weekend dumb down iScript to syntax level close to BrightScript.
Then I should be able to craft some magic to expose the Java components that I've been putting together in a manner simular to how they are accessed by BrightScript...
Then, I will need to do a little work to make iScript more like BrightScript, not too much work...
Then, I will need to cook up some Swing/AWT thingy that will be the emulator UI that the developer and or tester will use for example to say that the video has stopped playing...
Finally, I will need to change iBuild (the IDE) to be able to package and deploy to the Roku player and to bake package for distribution... So that the user can just press some button or select some menu item and not have to go to the Web interface, but that has lower priority.
Oh, one more thing, as soon as I have something, I'll post it for all...
cheers
when i do get something out I can use some help by people who are familiar with developing on Roku and the Roku Components and Language testing my work and maybe even getting involved in its development...
cdoty
Streaming Star
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2011
09:50 AM
Re: re: Roku / BrightScript Emulator
"goya" wrote:
when i do get something out I can use some help by people who are familiar with developing on Roku and the Roku Components and Language testing my work and maybe even getting involved in its development...
Hi goya,
Sounds like an useful project. I'm interested to see what you come up with. Being able to debug code and see the results on a computer would be very nice.
btpoole
Channel Surfer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2015
07:05 AM
Re: re: Roku / BrightScript Emulator
Was anything ever completed on the emulator. Very interested in seeing it.
Thanks
Thanks

Komag
Roku Guru
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2015
01:54 PM
Re: re: Roku / BrightScript Emulator
goya's last post was only a week or two later, over 4 years ago, so I'm sure this project died

RokuJoel
Binge Watcher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2015
02:25 PM
Re: re: Roku / BrightScript Emulator
Unlikely that we will produce an emulator.
- Joel
- Joel
jasonbio
Visitor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2015
07:15 AM
Re: re: Roku / BrightScript Emulator
If you're looking for a semi-solution, instanttvchannel.com's channel builder is pretty close to being an exact representation of what your channel will look like cosmetic wise. So, if that's all you're after then I think that'd work well.