similar to: iOS Parsing Error

Hi guys. Total newbie here. I''ve been doing web stuff since 1996 but only began the foray into scripting last year. I haven''t got my skull completely 360 degrees around OOP yet. It''s just me here (in Japan) and there are no Ruby groups in my area (never mind any in English). I''ve got a database table - real simple: question, answer, and id fields - and I

Ok to start I'm a noob. Not a complete noob, but you may as well assume I wont know how to do something more complex than opening a terminal. I just switched my own computer to ubuntu and I wanted to bring along my copy of pse7 if possible. I followed the guide listed here http://www.makeuseof.com/tag/idiots-guide-installing-photoshop-cs5-ubuntu-1004/ and after a few fumbles and near miss

Not sure if this is the right place to ask. Please let me know if there's a better place. I ran the clang static analyzer via Xcode 4.6.3 on our project that uses a lot of third-party libraries. One of them is Google protobufs, and it has a set of non-exiting assertion macros that the analyzer (rightly) ignores when flagging some NULL dereferences. The macros look like this: #define

Hello, The package builds successfully on RHEL5 and OS X( 64 bit,32/64 respectively) but on FC4(32 bit) it fails with this error g++ -m32 -I/usr/include/R -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -I. -g `pkg-config --cflags protobuf` -Wall -c

Hello, I'm trying to use the limited connections api defined in Rinternals.h. I have code that looks like this (inspired from do_serializeToConn) : SEXP serialize_to_connection( SEXP xp, SEXP connection ){ Rconnection con ; struct R_outpstream_st out; R_pstream_format_t type = R_pstream_binary_format ; SEXP (*hook)(SEXP, SEXP) = NULL ; con = getConnection(Rf_asInteger(connection));

Hello, I have a question about how to set up a Makefile that generate a .so that I can load into opt without getting duplicate symbols. Here's what I have right now: LIBRARYNAME=previrt SHARED_LIBRARY=previrt LINK_COMPONENTS := transformUtils LINK_LIBS_IN_SHARED=1 include $(LEVEL)/Makefile.common LIBS += -lprotobuf CPPFLAGS += -I${HOME}/.root/usr/include -DGOOGLE_PROTOBUF_NO_RTTI LDFLAGS

I thought it would, but it seems to be missing the CloneModule symbol (which isn't called from anywhere in the LLVM codebase). On Fri, Jul 15, 2011 at 7:43 AM, John Criswell <criswell at illinois.edu>wrote: > On 7/14/11 7:36 PM, Gregory Malecha wrote: > > Hello, > > I have a question about how to set up a Makefile that generate a .so that I > can load into opt

On 7/14/11 7:36 PM, Gregory Malecha wrote: > Hello, > > I have a question about how to set up a Makefile that generate a .so > that I can load into opt without getting duplicate symbols. Here's > what I have right now: Have you tried removing LINK_COMPONENTS below? I suspect that the opt binary already contains everying in the transformUtils library. -- John T. > >

Possibly protobuf or capn proto would be much more clean alternatives to json. I was working with interpreting instruction semantics a while back, and you shouldn't have to write a parser to get the data structure back into coherent form, you can get what you want automatically and have the structure isolated into a common schema. On Sat, Jun 20, 2015 at 9:22 AM, Stephen Cross <scross at

Hi Gregory, I had a similar problem a while back, see: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-June/032508.html for my solution to this problem. Basically I ended up linking in the *.o files needed to get exactly what I needed (in your case, the file defining CloneModule and whatever else you need), without pulling in too much (causing duplicate symbol issues with opt). Hopefully this

Hello all, I am trying to port the package RProtoBuf to windows. The developers of RProtoBuf have given me some helpful pointers so far, but now I am stuck. After having made what I think are the necessary changes to the package to compile on windows, "R CMD build RProtoBuf" outputs a somewhat cryptic error ("This application has requested the Runtime to terminate it in an unusual

Hello, Has anyone managed to successfully compile the latest 3.13.2 under FreeBSD 11.1? ./autogen.sh and ./configure seem to work but make fails: Making all in src CC glfs.lo cc: warning: argument unused during compilation: '-rdynamic' [-Wunused-command-line-argument] cc: warning: argument unused during compilation: '-rdynamic' [-Wunused-command-line-argument] fatal

LLVM Weekly - #189, Aug 14th 2017 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/189>. Welcome to the one hundred and eighty-ninth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

Hi, I notice that the CRAN binary for the macOS version of RProtoBuf is built against quite an old version of protocol buffers (from 2014, before v3 format support was added). the windows version is (blessedly) kept up-to-date, but I'd like to float the suggestion that the macOS version get an update too. with thanks jonathon

Considering engineering my own code-generator. If I do go ahead, will open-source the end result. Needs to read [parse] one language, and output JSON (conformant to a specific JSON-schema). Then needs to read JSON, and reproduce the code in that language, and [possibly] merge the generated code with existing code. Languages I'm looking to support are all rather popular (Python, Go, Rust,

I looked into this further. ld64 has a macho_nlist abstraction over the various underlying nlist structures [1]. On x86-64, the P::getP referenced in n_value will resolve to [2], which in turn goes to [3], which calls OSReadLittleInt64. On a little endian machine, OSReadLittleEndian just calls _OSReadInt64 [4], which in turn does a pointer arithmetic and cast and then dereferences the pointer [5].

Hi Simon, Thanks for your feedback. -- this is an observation that I wasn't considering when I wrote this mainly because I am, in fact, working with rather small data sets. BTW: There is code there, it's under the bitbucket link -- here's the direct link if you'd still like to look at it: https://bitbucket.org/CoherentLogic/jdataframe Re "for practical purposes is

Hello everybody, by the way, speaking about the r-cran-rcurl package in Ubuntu, the versions in trusty and vivid are linked by error to the "NSS" flavour of libcurl3 instead of the "OpenSSL flavour", which cause at least problems when using the CRAN devtools package. A bit more details are available in the Debian bug tracking system (https://bugs.debian.org/786473). I am not

> On Jan 15, 2016, at 12:35 PM, Thomas Fuller <thomas.fuller at coherentlogic.com> wrote: > > Hi Simon, > > Thanks for your feedback. -- this is an observation that I wasn't > considering when I wrote this mainly because I am, in fact, working > with rather small data sets. BTW: There is code there, it's under the > bitbucket link -- here's the direct

Hey Bjorn, Were you able to figure this out or is it still broken for you? Our scenario is a little bit different, but I have a theory as to what may be going wrong. What linker are you using when you compile your project with clang-cl? I am wondering whether the version of the linker and/or the libraries that you are using is too old in comparison to the one used for the clang compilation.