Has anyone successfully ported googleTest to a real time process in WindRiver 3.0 / VxWorks 6.6 ?
I am able to get gtest to build, but I get a few errors when linking. I can modify these specific sections of code, but that only produces run time errors.
here is what I'm seeing:
googleTest.so: undefined reference to isascii(int)'
googleTest.so: undefined reference togettimeofday'
googleTest.so: undefined reference to `strcasecmp'
I have 2 shared Libraries (.so): 1 for gtest and 1 for gtest_main. I have 1 RTP (real time process) where I have my test code.
Note:
To get googletest to compile in vxworks, I had to modify some of the Flags: Specifically:
GTEST_HAS_POSIX_RE - 0
GTEST_HAS_TR1_TUPLE - 0
GTEST_HAS_STREAM_REDIRECTION 0
Any insight or advice is much appreciated.
Turns out the way the Kernel was configured was incorrect.
To remedy the problem, I actually made a brand new kernel; keeping all of the default settings. This worked.
VxWorks is not yet supported by Google Test.
Also note that there may need to be certain changes made to the code to support the platform. For example, getClockTime may not exist and the code have to be altered to use a user defined method.
I think there is a unique solution based on your platform, target and sim; and your development environment. As well as versions of the tool (vxworks / wind-river etc).
Googletest does seem to be supported on vxworks7
https://github.com/Wind-River/vxworks7-google-test/blob/master/README.md
I have compiled it, and built a DKM, but at the moment it does not seem to be supporting any tests, so I am not sure what is going on there
Related
I trying to write some game, based on Love2d framework, compiled from moonscript. Every time when I make a mistake in my code, my application throws error and this error refers to compiled lua-code, but not a moonscript, so I have no idea where exactly this error happens. Tell me please, what a solution in this situation? Thanks.
Moonscript does support source-mapping/error-rewriting, but it is only supported when running in the moon interpreter: https://moonscript.org/reference/command_line.html#error_rewriting
I think it could be enabled in another lua environment but I am not completely sure what would be involved.
It would definetely require moonscript to hold on to the source-map tables that are created during compilation, so you couldn't use moonc; instead use the moonscript module to just-in-time compile require'd modules:
main.lua
-- attempt to require moonscript,
-- for development
pcall(require, 'moonscript')
-- load the main file
require 'init'
init.moon
love.draw = ->
print "test"
with this code and moonscript properly installed you can just run the project using love . as normal. The require 'moonscript' call will change require to compile moonscript modules on-the-fly. The performance penalty is negligible and after all modules have been loaded there is no difference.
Debugging is a problem for pretty much any source-to-source compilation system. The target language has no idea that the original language exists, so it can only talk about things in terms of the target language. The more divergent the target and original languages are, the more difficult debugging will be.
This is a big part of the reason why C++ compilers don't compile to C anymore.
The only real way to deal with this is to become intimately familiar with how the Moonscript compiler generates Lua from your Moonscript code. Learn Lua and carefully read the output Lua, comparing it to the given Moonscript. That will make it easier for you to map the given Lua error and source code to the actual Moonscript code that created it.
SBT 0.13.1 and Scala 2.10.3.
We have implemented a plugin that sets the dependencyOverrides to standard artifact versions. My dependencyOverrides set is about 950 artifacts large. Not that we have all these dependencies but this is the standard versions people need to use.
After implementing the overrides, sbt update times (a reference project with 11 sub-projects) on Mac (Mac OS 10.7.5, Oracle JDK 1.7.0_45) jumped from ~30 seconds to ~140 seconds. The referenced artifacts are actually smaller as this gets rid of many duplicate artifacts of different versions.
I've run sbt under -Xprof to see what is the problem and found this major difference:
Before dependencyOverrides:
Compiled + native Method
3.2% 10 + 0 org.apache.ivy.core.module.id.ModuleRules.getRules
After dependencyOverrides:
Compiled + native Method
31.6% 136 + 2 org.apache.ivy.core.module.id.ModuleRules.getRules
Xprof doesn't give me invocation counts. But from a brief review of ModuleRules.getRules there seem to be not much complexity. That gives me a hint the invocation count may have skyrocketed. I'll have to use different profilers to get a better grip.
Unfortunately, Scala/SBT plugin for IntelliJ constantly causes a sbt resolve and the user experience is that much worse. I'd like to run this by others who may have run into this issue before or even know of a good way to fix it (short of diving into ivy code and figuring out the issue + modifying ivy code myself).
Thanks in advance for any input.
Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.
So, my dilemma here is pretty much the fact that I have GData included with static headers in my file per the instructions found here: http://hoishing.wordpress.com/2011/08/23/gdata-objective-c-client-setup-in-xcode-4/. Everything compiles correctly and such and I can run the Analyzer just fine. The minute I try to run the profiler to check for leaks, it hits the attached error The service placeholder compiler flag should be replaced by actual service specifications as seen below:
I'm not %100 sure on what I need to do to make this an acceptable service.. or why it triggers this error. Implementing GData was already a not-so-fun walk in the park. (Thank you the guy who added his static tutorial in google's documentation.. lack of documentation). Does anyone know specifically what needs to be done and/or how?
From the docs...
There is a conditional set in the static library target as a reminder
to developers to define the needed services. For your project, replace
or delete the definition
-DGDATA_INCLUDE_nameServiceHere_SERVICE=1
in the Other C Flags section of the static library target's Release
configuration.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.