search for: test_object

...t of ActiveRecord::Base somewhere (you could just use an existing object and add an attr_accessor to it, of course), here''s what you would put in the controller: Model code: class X < ActiveRecord::Base attr_accessor :test_attr end Controller code: public def test_action test_object = X.new session[:test_object] = test_object session[:test_object].test_attr = 5 render(:action => ''index'') end public def test_action2 puts "Value is: #{session[:test_object].test_attr}" render(:action => ''index'') end...

...e? I''m sure I''m missing something simple.... I realize that I''m not saving the object to the database, I''ve got a requirement to create and manipulate it in memory before persisting it. Thanks in advance to anyone who may help! Test/app/db/migrate/001_create_test_objects.rb ------------------------------------------------------------------ class CreateTestObjects < ActiveRecord::Migration def self.up create_table :test_objects do |t| t.column :name, :string t.column :test_array, :string end end def self.down drop_table :test_objec...

...nitizers and xray) has a number of unit tests which could really just be built as normal binaries and invoked appropriately. If we're avoiding ctest [1], then for the unit tests in compiler-rt I'd like to see whether just using normal binaries can make the build faster. The 'Generating TEST_OBJECTS.*' messages seem to indicate that these are executed sequentially, or cannot be parallelized by ninja-build [2] and take a really long time to complete. Thoughts? [0] https://cmake.org/cmake/help/v3.4/command/add_test.html [1] https://cmake.org/cmake/help/v3.4/manual/ctest.1.html#manual:ctes...

...; "" "SOURCES;HEADERS" ${ARGN}) > if(UNIX AND NOT APPLE) > set(CMAKE_DL_LIBS_INIT "") > - foreach(lib ${CMAKE_DL_LIBS}) > - list(APPEND CMAKE_DL_LIBS_INIT -l${lib}) > - endforeach() > foreach(arch ${XRAY_TEST_ARCH}) > set(TEST_OBJECTS) > get_xray_lib_for_arch(${arch} XRAY_RUNTIME_LIBS) > @@ -55,9 +60,7 @@ macro(add_xray_unittest testname) > RUNTIME "${XRAY_RUNTIME_LIBS}" > DEPS gtest xray > CFLAGS ${XRAY_UNITTEST_CFLAGS} > - LINK_FLAGS ${TARGET_LINK_FLAGS} > -...

...stdc++" to the end, just after > "-lrt" it should work. Thanks, Tim. I don't see "-lrt": $BASE/llvm_Rel400/projects/compiler-rt/lib/xray/tests/CMakeLists.txt 43 if(NOT APPLE) 44 add_compiler_rt_test(XRayUnitTests ${testname} 45 OBJECTS ${TEST_OBJECTS} 46 DEPS ${TEST_DEPS} 47 LINK_FLAGS ${TARGET_LINK_FLAGS} 48 -lstdc++ -lm ${CMAKE_THREAD_LIBS_INIT} 49 -lpthread 50 -L${COMPILER_RT_LIBRARY_OUTPUT_DIR} -lclang_rt.xray-fdr-${arch}) 51 endif()

...RCES;HEADERS" ${ARGN}) >> if(UNIX AND NOT APPLE) >> set(CMAKE_DL_LIBS_INIT "") >> - foreach(lib ${CMAKE_DL_LIBS}) >> - list(APPEND CMAKE_DL_LIBS_INIT -l${lib}) >> - endforeach() >> foreach(arch ${XRAY_TEST_ARCH}) >> set(TEST_OBJECTS) >> get_xray_lib_for_arch(${arch} XRAY_RUNTIME_LIBS) >> @@ -55,9 +60,7 @@ macro(add_xray_unittest testname) >> RUNTIME "${XRAY_RUNTIME_LIBS}" >> DEPS gtest xray >> CFLAGS ${XRAY_UNITTEST_CFLAGS} >> - LINK_FLAGS ${TARGET...

...objects do NOT provoke this bug. (program attached) 6) There are no interrupts between CACHE_ERRORs, so it's not caused by race in cache_error/software method handling. Any ideas how to debug it? Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: test_objects.tar.gz Type: application/octet-stream Size: 2399 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20121220/a790fe23/attachment.obj>

Hi, I am trying to build the LLVM suite on a RedHat Enterprise Linux clone (Scientific Linux <https://www.scientificlinux.org/>). In the latest attempt, the build seems to complete without any explicit failures but the `check-all` process fails. Any ideas about what is wrong or suggestions for how to proceed would be much appreciated. This is the current procedure: sudo yum install