jfo

le 'libembedded_lld_lib.a(SymbolTable.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'bool llvm::DenseMapBase<llvm::DenseMap<llvm::DISubrange*, llvm::detail::DenseSetEmpty, llvm::MDNodeInfo<llvm::DISubrange>, llvm::detail::DenseSetPair<llvm::DISubrange*> >, llvm::DISubrange*, llvm::detail::DenseSetEmpty, llvm::MDNodeInfo<llvm::DISubrange>, llvm::detail::DenseSetPair<llvm::DISubrange*> >::LookupBucketFor<llvm::DISubrange*>(llvm::DISubrange* const&, llvm::detail::DenseSetPair<llvm::DISubrange*> const*&) const' from file '/Users/jfo/local/lib/libLLVMCore.a(Metadata.cpp.o)' to global weak symbol 'guard variable for llvm::hashing::detail::get_execution_seed()::seed' from file 'libembedded_lld_lib.a(SymbolTable.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different vi

jfo

Undefined symbols for architecture x86_64:
  "_xmlAddChild", referenced from:
      treeMerge(_xmlNode*, _xmlNode*) in libLLVMWindowsManifest.a(WindowsManifestMerger.cpp.o)
  "_xmlCopyNamespace", referenced from:
      treeMerge(_xmlNode*, _xmlNode*) in libLLVMWindowsManifest.a(WindowsManifestMerger.cpp.o)
  "_xmlDocDumpFormatMemoryEnc", referenced from:
      llvm::windows_manifest::WindowsManifestMerger::WindowsManifestMergerImpl::getMergedManifest() in libLLVMWindowsManifest.a(WindowsManifestMerger.cpp.o)
  "_xmlDocGetRootElement", referenced from:
      llvm::windows_manifest::WindowsManifestMerger::WindowsManifestMergerImpl::merge(llvm::MemoryBuffer const&) in libLLVMWindowsManifest.a(WindowsManifestMerger.cpp.o)
      llvm::windows_manifest::WindowsManifestMerger::WindowsManifestMergerImpl::getMergedManifest() in libLLVMWindowsManifest.a(WindowsManifestMerger.cpp.o)

jfo

~/local/bin/llvm-config --libs

-lLLVMLTO -lLLVMPasses -lLLVMObjCARCOpts -lLLVMMIRParser -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoDWARF -lLLVMCoverage -lLLVMTableGen -lLLVMDlltoolDriver -lLLVMOrcJIT -lLLVMWebAssemblyDisassembler -lLLVMWebAssemblyCodeGen -lLLVMWebAssemblyDesc -lLLVMWebAssemblyInfo -lLLVMWebAssemblyAsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMSystemZDisassembler -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMSparcDisassembler -lLLVMSparcCodeGen -lLLVMSparcAsmParser -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMSparcAsmPrinter -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lL

jfo

[ 99%] Building CXX object CMakeFiles/zig.dir/src/translate_c.cpp.o
[100%] Linking CXX executable zig
Undefined symbols for architecture x86_64:
  "llvm::ARMBankedReg::lookupBankedRegByName(llvm::StringRef)", referenced from:
      (anonymous namespace)::ARMAsmParser::tryCustomParseOperand(llvm::SmallVectorImpl<std::__1::unique_ptr<llvm::MCParsedAsmOperand, std::__1::default_delete<llvm::MCParsedAsmOperand> > >&, unsigned int) in libLLVMARMAsmParser.a(ARMAsmParser.cpp.o)
      (anonymous namespace)::ARMDAGToDAGISel::Select(llvm::SDNode*) in libLLVMARMCodeGen.a(ARMISelDAGToDAG.cpp.o)
  "llvm::ARMBankedReg::lookupBankedRegByEncoding(unsigned char)", referenced from:
      llvm::ARMInstPrinter::printBankedRegOperand(llvm::MCInst const*, unsigned int, llvm::MCSubtargetInfo const&, llvm::raw_ostream&) in libLLVMARMAsmPrinter.a(ARMInstPrinter.cpp.o)
  "llvm::MemoryBuffer::getNewUninitMemBuffer(unsigned long, llvm::Twine const&)", referenced from:
      clang::SrcMgr::ContentCache::getBuffer(clang::DiagnosticsEngine

jfo

what is the advantage of the state machine vs a recursive descent parser, are the equivalent, different?
so the recursive descent parser is the parser stage

would be great to have a list of flags that output the ast and verbose ast etc in order of each and every step

can a zig ast be too big for the memory in the machine? That would probably be enormous, right?

zig ir, how important is it to how zig works?  I didn't know zig had its own ir, how early in the devlepment was that introduced?

is the self hosted compiler able to talk to llvm directly as well? importing the c++ symbols directly?

jfo

mkdir /tmp/lol
echo "console.log('hello from lol/index.js')" > /tmp/lol/index.js
echo -n "node /tmp/lol: "
node /tmp/lol
echo "console.log('hello from lol.js')" > /tmp/lol.js
echo -n "node /tmp/lol.js: "
node /tmp/lol.js
echo -n "node /tmp/lol: "
node /tmp/lol
echo halp

jfo

diff --git a/middleware/brute_factory.js b/middleware/brute_factory.js
index 3f8171ff6..3afbbe247 100644
--- a/middleware/brute_factory.js
+++ b/middleware/brute_factory.js
@@ -20,7 +20,7 @@ const storeFactory = _.once(() => {
 
 module.exports = function bruteFactory(options) {
   options = _.defaults(options || {}, {
-    freeRetries: 5,
+    freeRetries: Infinity,

jfo

commit 6b3a2d397c0ef4c904116f9a131399a740b74c44
Author: Jeff Fowler <[email protected]>
Date:   Mon Feb 5 13:40:40 2018 +0100

    update package.lock

diff --git a/package-lock.json b/package-lock.json
index fb9b401..fe78e06 100644
--- a/package-lock.json
+++ b/package-lock.json

jfo

pub const pubStruct = struct {
    pub fn pubStatic() u8 { return 1; }
    fn privStatic() u8 { return 2; }

    pub fn pubInstance(self: pubStruct) u8 { return 3; }
    fn privInstance(self: pubStruct) u8 { return 4; }

    pub const pubThing:u8 = 5;
    const privThing:u8 = 6;
};

jfo

const warn = @import("std").debug.warn;

pub const pubStruct = struct {
    pub fn pubStatic() u8 { return 1; }
    fn privStatic() u8 { return 2; }

    pub fn pubInstance(self: pubStruct) u8 { return 3; }
    fn privInstance(self: pubStruct) u8 { return 4; }

    pub const pubThing:u8 = 5;