I want to make text to speech converter,
I found java have provided free TTS (Text to Speech) to do this,
but i don't know how to implement in blackberry.
Please help me to use it.
From the freetts faq, the code requires JDK 1.4, so is using features that aren't available on the blackberry device java API:
Why must I use Java 2 SDK, Standard Edition, v1.4?
Some of the many compelling reasons to use Java 2 SDK, Standard
Edition, v1.4. are:
New IO package - Java 2 SDK, Standard Edition, v1.4 provides a new IO
(java.nio) package that provides memory mapped file I/O. This package
drastically reduces the load times of the FreeTTS databases. Regular
expressions - Java 2 SDK, Standard Edition, v1.4 provides a new
package for regular expression matching (java.util.regex). They are
used in the FreeTTS text normalization step. Assert Facility - Java
2 SDK, Standard Edition, v1.4 added the new assert keyword to ensure
that certain conditions are satisfied before continuing execution.
FreeTTS uses this keyword in all stages of speech synthesis.
Compiler Optimizations - Java 2 SDK, Standard Edition, v1.4 has
numerous compiler optimizations that produce faster and more compact
code. For example, with the -server switch, byte codes are optimized
to eliminate bounds checking on array accesses whenever possible.
Related
In the context of C++ toolchain, I am trying to understand the difference of the concept between cc_toolchain_suite and register_toolchains, to me it seems they achieve the same purpose: select a toolchain based on command line parameters.
See https://docs.bazel.build/versions/master/toolchains.html for register_toolchains
See https://docs.bazel.build/versions/master/cc-toolchain-config-reference.html for cc_toolchain_suite
Can someone please help understand the subtlety behind these 2 concepts?
TL;DR The cc_toolchain_suite is part of the legacy toolchain configuration system. It still exists in Bazel because the migration to the new API is not complete. The register_toolchains is part of the newer, unified toolchain API. When possible use register_toolchains instead of cc_toolchain_suite/--*crosstool_top
Originally the concept of a 'toolchain' was not standardised in Bazel, so a Java toolchain would be implemented very differently than a cc toolchain.
Before the unified starlark toolchain API, cc toolchains were specified in proto-text formatted 'CROSSTOOL' files.
With the introduction of the platforms API and the unified toolchains API, the concepts in the CROSSTOOL files were converted almost 1:1 to the new unified platforms/toolchains starlark API. This was mostly to ensure that there was compatibility between the old/new API's.
One of the concepts in the older 'CROSSTOOL' configuration system was a 'toolchain suite', that allowed you to define a group of toolchains targeting different CPU's (This was before the platforms API was introduced).
As far as I understand the only reason that cc_toolchain_suite is still a part of Bazel's starlark API is that some of the apple/android toolchains have not yet been completely migrated across.
Here are a few examples of where I've opted to using the newer register_toolchains approach. Note that these toolchains do not use cc_toolchain_suite anymore.
I'd like to learn how to use the OpenCL API, however I am a bit confused about how to "install" OpenCL for development. The various articles on Google are conflicting and I suspect some are obsolete.
My understanding is that Khronos group provides the specification and then various companies provide an SDK that complies with that specification.
As I understand it you need:
The OpenCL headers, which can be downloaded from the Khronos site
The OpenCL library, which comes with the various SDKs
Is there a difference between the different SDKs? From what I can tell the options are Intel, AMD or Nvidia. I've read conflicting information about whether it matters what SDK you use - some sources say that the SDK is just for the developer and the binaries that are produced will work on any hardware that supports OpenCL while other sources say that using a particular SDK locks your application into one vendors hardware. Which is it? Does it matter which SDK I choose to use and is there a non-vendor specific OpenCL library that I can link to?
OpenCL SDKs are different. They provide tools to ease the developing, additional functions, samples, and documentation.
Every manufacturer will include what it suits best their hardware, but they all should be compatible when the app is compiled.
The ".lib" ".a" OpenCL library that gets linked into the app (the one that comes in the SDK) is the same in all the cases (except if they have different versions, 1.1, 1.2, 2.0).
This is because the library is not really a library, but only a stub to the real functions in the real driver. This also explains why the headers are all the same, they all link against the same library.
All the apps, no matter what SDK should be the same after compiling.
In the case of nVIDIA, additionally to their OpenCL.lib, they provide some functions to ease the platform acquisition (oclGetPlatformID() in oclUtils.h) and so on, that are not available on other drivers, and it is recomended NOT to use them unless you want to end up having to pack another nVIDIA propietary library to your app.
But if you really want to be generic, then you should go for dynamic library loading (dload(), LoadLibrary()). Which will make your app work even in situations where the system does not even have OpenCL installed.
You are correct, all SDKs use (or should use) the Khronos headers. You could also just use the Khronos headers yourself.
On Windows, you'd link to OpenCL.lib, which is just a static wrapper around OpenCL.dll (installed by your graphics driver in \Windows\System32). Everyone's wrapper should be similar for the same version of OpenCL. It is also supplied by Khronos (the ICD is open source) but it is easier to use one from an SDK.
OpenCL.dll uses the ICD mechanism to load the runtime(s) installed by each driver. If you have multiple runtimes installed, they each show up as a cl_platform.
If you are targeting OpenCL 1.1 (due to NVIDIA) I suggest using the version 1.1 header to ensure you don't accidentally use newer API.
While the OpenCL aims to abstract code from hardware, there are several different types of GPU architectures. These differences force writing specific code for specific hardware. Hence it is not easy to write a portable code. IMHO, you are better off selecting one hardware and utilize developer friendly SDK for that platform.
What is the use case you are trying to solve?
The binaries can be compiled at runtime (at least in Java). Therefore a OpenCL-C-runtime (?) is needed, but the compiled kernel are mostly hardware-dependent.
Does Delphi support ARMv5 and ARMv6 CPU's and is there a way to make my app work on them?
The answer is no because Delphi compiles native code targeted at a specific CPU, in this case ARMv7 with NEON support.
David I posted this on the subject:
Brian Long gives additional Android requirements in his blog post at
http://blog.blong.com/2013/09/delphi-for-android-aka-delphi-xe5-aka.html?showComment=1378942045563&m=1
Here is what he lists from our Documentation:
Android requirements
Because the Delphi compiler generates native machine instructions, its
output is processor-specific. In other words it doesn’t target the
Dalvik Virtual Machine, where regular Android applications reside,
which are basically Java p-code applications that are executed by a
variant of the Java VM. Instead it generates raw machine code, as all
the current wave of Delphi compilers do (the long gone Delphi for .NET
was the exception to this general rule). So because it’ a compiler
compiling native machine instructions Delphi’s Android support has the
following requirements:
there must be a GPU
the CPU must be ARMv7 with NEON instruction support
the OS on the target device must be one of: GingerBread: Android
2.3.3+ (MR1 or later), which is API level 10 Ice Cream Sandwich: Android 4.0.3+ (MR1 or later), which is API level 15 Jelly Bean:
Android 4.1+ (release, MR1, MR2 or later), which are API levels 16, 17
and 18
Embarcadero clearly states in their manual what is supported.
As far as I know (and what embarcadero tells on the RAD studio road shows), for Android at least ARM v7 with NEON support is required.
Edit: The (German) data sheet states "Android-Smartphones und –Tablet-Computer: ARMv7-Geräte mit NEON-Unterstützung," on the bottom of the last page.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/
When i compiled my application in blackberry it shows the following error.
generics are not supported in -source 1.3
(use -source 5 or higher to enable generics)
how to solve this
Java 1.3 is barbaric and no one should ever have to suffer its indignities. Fortunately, there is a solution!
Generics, enums, changing return signature in overrides, and pretty much everything that makes java usable was introduced in java 1.5. (see http://en.wikipedia.org/wiki/Java_version_history). Fortunately, most of java 1.5 was designed to be backwards compatible and not require JVM / bytecode changes. (or maybe this was unfortunate, as it lead Java's implementation of generics to be much weaker than C#. just try creating a generic class with static methods / fields that use the generic parameter)
This IBM article does a good job of explaining the background:
http://www.ibm.com/developerworks/java/library/j-jtp02277.html
But this JVM similarity allowed for creation of tools such as:
http://retrotranslator.sourceforge.net/
This is the section from my Ant buildfile that calls retrotranslator:
< java jar="${transformer.jar.exe}"
fork="true"
classpath="${epic-framework.dir}/tools/retrotranslator-runtime13-1.2.9.jar:${epic-framework.dir}/tools/retrotranslator-runtime-1.2.9.jar"
args="-srcjar ${build.dir}/classes5.jar -target 1.3 -destjar ${build.dir}/classes5to3.jar"
/>
Run the converted jar through preverify.exe and then give it to rapc.exe and you will have a working Blackberry app written with Java 1.5.
Edit: I missed a key detail in my original post. In addition to being Java 1.3, the Blackberry class hierarchy is missing many classes that would normally be a part of a Java SE 1.3 JDK. The one you will hit first is StringBuilder -- javac transforms ("string" + "otherstr" + "blah blah") into StringBuilder.append("string").append("otherstr").append("blah blah"). That class doesn't exist on BB, so you break. However, BB has StringBuffer, so writing an adapter between the two is pretty easy. The one catch is that BB disallows apps from adding classes into java.*. This can be very effectively fixed in the build process: 1) build your app against Java 1.5 w/ java.lang.StringBuilder on the classpath, 2) string transform java.lang.Stringbuilder (and everything else in your compat shim) to live in com.mycorp.java.lang.StringBuilder and build it into a JAR file. 3) Use that JAR file w/ retrotranslator and retrotranslator will update all bytecode references to java.lang.StringBuilder so that they now point to com.mycorp.java.lang.StringBuilder. Now you have a java 1.3 compatible bytecode that can be run on a Blackberry.
If anyone is interested in this stuff, contact me. I could look into open sourcing the compat library I have.
This is a limitation of J2ME, which uses a subset of the J2SE (no collections, reflection, etc.) and a Java language level of 1.3. Any code written for J2SE will most likely need to be manually ported.
It seems the JDK5 is not yet supported.
Same question was asked on the blackberrry forum but about enum support:
Sadly, the BlackBerry api is very behind in terms of Java versioning. There's no Generics, no Maps, no Enums - it's based around JDK 1.3.
I believe there is no way of enabling this feature within your BlackBerry app. If you find one, I'd be very interested to hear about it.