text:
Cannot Build: compareSizes

/----------
| Run Ghc Stage1 (package = compareSizes)
|     input: utils/compare_sizes/stage1/build/Main.o
| => output: utils/compare_sizes/stage1/build/tmp/compareSizes
\----------
Undefined symbols for architecture x86_64:
  "_TRACE_gc", referenced from:
      _traceEventHeapInfo in libHSrts.a(Storage.o)
      _traceEventGcStats in libHSrts.a(Stats.o)
  "_TRACE_sched", referenced from:
      _traceTaskCreate in libHSrts.a(Schedule.o)
      _traceTaskCreate in libHSrts.a(RtsAPI.o)
      _traceTaskDelete in libHSrts.a(RtsAPI.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`clang' failed in phase `Linker'. (Exit code: 1)
shakeArgsWith    0.002s    0%
Function shake   0.030s    0%
Database read    0.128s    0%
With database    0.012s    0%
Running rules  294.047s   99%  =========================
Total          294.219s  100%
Error when running Shake build system:
* utils/compare_sizes/stage1/build/tmp/compareSizes
user error (Development.Shake.cmd, system command failed
Command: inplace/bin/ghc-stage1 -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db -package-id base-4.9.0.0 -package-id directory-1.2.5.0 -package-id filepath-1.4.1.0 -i -iutils/compare_sizes/stage1/build -iutils/compare_sizes/stage1/build/autogen -iutils/compare_sizes -Iutils/compare_sizes/stage1/build -Iutils/compare_sizes/stage1/build/autogen -I/Users/angerman/Projects/Haskell/ghc/libraries/directory/include -I/Users/angerman/Projects/Haskell/ghc/libraries/unix/include -I/Users/angerman/Projects/Haskell/ghc/libraries/time/lib/include -I/Users/angerman/Projects/Haskell/ghc/libraries/bytestring/include -I/Users/angerman/Projects/Haskell/ghc/libraries/base/include -I/Users/angerman/Projects/Haskell/ghc/libraries/integer-gmp/include -I/Users/angerman/Projects/Haskell/ghc/rts/dist/build -I/Users/angerman/Projects/Haskell/ghc/includes -I/Users/angerman/Projects/Haskell/ghc/includes/dist-derivedconstants/header -optP-include -optPutils/compare_sizes/stage1/build/autogen/cabal_macros.h -XHaskell2010 -odir utils/compare_sizes/stage1/build -hidir utils/compare_sizes/stage1/build -stubdir utils/compare_sizes/stage1/build -rtsopts -H32m -O2 -Wall -fwarn-tabs -no-auto-link-packages -optl-liconv -optl-lm -optl-ldl -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/directory/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/unix/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/time/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/filepath/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/bytestring/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/deepseq/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/array/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/base/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/integer-gmp/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/ghc-prim/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/rts/dist/build utils/compare_sizes/stage1/build/Main.o -o utils/compare_sizes/stage1/build/tmp/compareSizes
Exit code: 1
Stderr:
Undefined symbols for architecture x86_64:
  "_TRACE_gc", referenced from:
      _traceEventHeapInfo in libHSrts.a(Storage.o)
      _traceEventGcStats in libHSrts.a(Stats.o)
  "_TRACE_sched", referenced from:
      _traceTaskCreate in libHSrts.a(Schedule.o)
      _traceTaskCreate in libHSrts.a(RtsAPI.o)
      _traceTaskDelete in libHSrts.a(RtsAPI.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`clang' failed in phase `Linker'. (Exit code: 1)
)

This happens when we link rts/dist to rts/stage1, and copy libffi into place. (e.g. cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi.a)

Running the command by hand with -verbose yields:
inplace/bin/ghc-stage1 -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db -package-id base-4.9.0.0 -package-id directory-1.2.5.0 -package-id filepath-1.4.1.0 -i -iutils/compare_sizes/stage1/build -iutils/compare_sizes/stage1/build/autogen -iutils/compare_sizes -Iutils/compare_sizes/stage1/build -Iutils/compare_sizes/stage1/build/autogen -I/Users/angerman/Projects/Haskell/ghc/libraries/directory/include -I/Users/angerman/Projects/Haskell/ghc/libraries/unix/include -I/Users/angerman/Projects/Haskell/ghc/libraries/time/lib/include -I/Users/angerman/Projects/Haskell/ghc/libraries/bytestring/include -I/Users/angerman/Projects/Haskell/ghc/libraries/base/include -I/Users/angerman/Projects/Haskell/ghc/libraries/integer-gmp/include -I/Users/angerman/Projects/Haskell/ghc/rts/stage1/build -I/Users/angerman/Projects/Haskell/ghc/includes -I/Users/angerman/Projects/Haskell/ghc/includes/dist-derivedconstants/header -optP-include -optPutils/compare_sizes/stage1/build/autogen/cabal_macros.h -XHaskell2010 -odir utils/compare_sizes/stage1/build -hidir utils/compare_sizes/stage1/build -stubdir utils/compare_sizes/stage1/build -rtsopts -H32m -O2 -Wall -fwarn-tabs -no-auto-link-packages -optl-liconv -optl-lm -optl-ldl -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/directory/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/unix/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/time/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/filepath/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/bytestring/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/deepseq/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/array/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/base/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/integer-gmp/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/libraries/ghc-prim/stage1/build -optl-L/Users/angerman/Projects/Haskell/ghc/rts/stage1/build utils/compare_sizes/stage1/build/Main.o -o utils/compare_sizes/stage1/build/tmp/compareSizes -v
Glasgow Haskell Compiler, Version 7.11.20151228, stage 1 booted by GHC version 7.10.2
Using binary package database: /Users/angerman/Projects/Haskell/ghc/inplace/lib/package.conf.d/package.cache
loading package database /Users/angerman/Projects/Haskell/ghc/inplace/lib/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0
wired-in package base mapped to base-4.9.0.0
wired-in package rts mapped to rts
wired-in package template-haskell not found.
wired-in package ghc not found.
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
Created temporary directory: /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0
*** C Compiler:
/usr/bin/clang -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0/ghc_1.c -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0/ghc_2.o -I/Users/angerman/Projects/Haskell/ghc/rts/stage1/build -I/Users/angerman/Projects/Haskell/ghc/includes -I/Users/angerman/Projects/Haskell/ghc/includes/dist-derivedconstants/header -fno-common -U__PIC__ -D__PIC__
*** Linker:
/usr/bin/clang -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -liconv -lm -ldl -L/Users/angerman/Projects/Haskell/ghc/libraries/directory/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/unix/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/time/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/filepath/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/bytestring/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/deepseq/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/array/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/base/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/integer-gmp/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/ghc-prim/stage1/build -L/Users/angerman/Projects/Haskell/ghc/rts/stage1/build -o utils/compare_sizes/stage1/build/tmp/compareSizes -Wl,-no_compact_unwind utils/compare_sizes/stage1/build/Main.o -L/Users/angerman/Projects/Haskell/ghc/libraries/directory/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/unix/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/bytestring/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/time/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/deepseq/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/array/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/filepath/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/base/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/integer-gmp/stage1/build -L/Users/angerman/Projects/Haskell/ghc/libraries/ghc-prim/stage1/build -L/Users/angerman/Projects/Haskell/ghc/rts/stage1/build /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0/ghc_2.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSdirectory-1.2.5.0 -lHSunix-2.7.1.1 -lHSbytestring-0.10.7.0 -lHStime-1.6 -lHSdeepseq-1.4.2.0 -lHSarray-0.5.1.0 -lHSfilepath-1.4.1.0 -lHSbase-4.9.0.0 -lHSinteger-gmp-1.0.0.0 -lHSghc-prim-0.5.0.0 -lHSrts -lCffi -liconv -lm -ldl
Undefined symbols for architecture x86_64:
  "_TRACE_gc", referenced from:
      _traceEventHeapInfo in libHSrts.a(Storage.o)
      _traceEventGcStats in libHSrts.a(Stats.o)
  "_TRACE_sched", referenced from:
      _traceTaskCreate in libHSrts.a(Schedule.o)
      _traceTaskCreate in libHSrts.a(RtsAPI.o)
      _traceTaskDelete in libHSrts.a(RtsAPI.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** Deleting temp files:
Deleting: /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0/ghc_4.rsp /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0/ghc_3.rsp /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0/ghc_2.o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0/ghc_1.c
*** Deleting temp dirs:
Deleting: /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc21085_0
`clang' failed in phase `Linker'. (Exit code: 1)

Some more info
/----------
| Run Ar (stage = Stage1, package = rts)
|     input: rts/stage1/build/Adjustor.o (and 86 more)
| => output: rts/stage1/build/libHSrts.a
\----------
ar: creating archive rts/stage1/build/libHSrts.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(Disassembler.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(LdvProfile.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(OldARMAtomic.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(Profiling.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(RetainerProfile.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(RetainerSet.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(RtsDllMain.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(Trace.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(EventLog.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: rts/stage1/build/libHSrts.a(Sanity.o) has no symbols

I am now stuck at this point too on Windows.

I'm building C files in rts using C compiler, however, the old build system is using GHC. I wonder whether this is relevant and I don't know why use GHC for compiling C files.

Here is the current command we use to produce Trace.o:
D:/msys/home/nam83/ghc/inplace/mingw/bin/gcc.exe
-Iincludes
-Iincludes/dist
-derivedconstants/header
-Irts/stage1/build
-Irts/stage1/build/autogen
-c rts/Trace.c
-o rts/stage1/build/Trace.o
-Irts
-Irts/stage1/build "
-DRtsWay=\"rts_v\""
-DCOMPILING_RTS "
-DProjectVersion=\"8.1.20160104\""

Here is what the old system uses:
"inplace/bin/ghc-stage1.exe"
-optc-fno-stack-protector
-optc-Wall
-optc-Wall
-optc-Wextra
-optc-Wstrict-prototypes
-optc-Wmissing-prototypes
-optc-Wmissing-declarations
-optc-Winline
-optc-Waggregate-return
-optc-Wpointer-arith
-optc-Wmissing-noreturn
-optc-Wnested-externs
-optc-Wredundant-decls
-optc-Iincludes
-optc-Iincludes/dist
-optc-Iincludes/dist-derivedconstants/header
-optc-Iincludes/dist-ghcconstants/header
-optc-Irts
-optc-Irts/stage1/build
-optc-DCOMPILING_RTS
-optc-fno-strict-aliasing
-optc-fno-common
-optc-Irts/stage1/build/autogen
-optc-Wno-error=inline
-optc-O2
-optc-fomit-frame-pointer
-optc-g
-optc-DRtsWay=\"rts_v\"
-optc-DWINVER=0x06000100
-optc-DProjectVersion=\"8.1.20160104\"
-static
-H32m
-O
-Wall
-Iincludes
-Iincludes/dist
-Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header
-Irts
-Irts/stage1/build
-DCOMPILING_RTS
-this-package-key rts
-dcmm-lint
-i
-irts
-irts/stage1/build
-irts/stage1/build/autogen
-Irts/stage1/build
-Irts/stage1/build/autogen
-O2
-c rts/Trace.c
-o rts/stage1/build/Trace.o

Quite a big difference, but I wonder which flag is crucial for this issue, and how the result is affected by the choice of builder (gcc vs ghc)

Strangely enough, my make log, lists -DDTRACE. And otherwise the only difference in the built file is -g, which adds debug information. Without -DDTRACE I get a 1.4k object file that contains nothing but debug info. Without -g I obtain an empty 200 byte file.
For -DDTRACE to work, I would need RtsProbes.h, which doesn't exist.

The big differences I see are:
-O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common

-O2 being the most important here, as it forces the inlining (or at least that's what I think).
In Trace.h we find:
INLINE_HEADER void traceEventHeapInfo(...) { ... }

for which includes/Stg.h contains the definition:
134:# define INLINE_HEADER static inline
163:# define INLINE_HEADER __inline static

As far as I can tell, for llvm's clang, -inline comes with -O2. Then again, I'm not sure if inline is actually supposed to be a hint to the compiler, or force the compiler to actually inline a function. Experimental results (-O0 vs -O2), imply the compiler handles it as a suggestion.
Can anyone more knowledgeable support make any sense out of this?

According to http://stackoverflow.com/questions/25602813/force-a-function-to-be-inline-in-clang-llvm/25623448#25623448, my suspicion is correct.

@angerman Awesome! Many thanks for finding the reason. I couldn't imagine -O2 affected linking... And I don't remember seeing any comments about this while looking through makefiles for a solution.

@snowleopard I ended up comparing the symbols in the object files, and wondered why they were missing in one, but not the other... after looking for the symbols in the source I kept wondering what was different wrt the inlining. Then it dawned on me that it had to be an optimization pass.

authors: angerman snowleopard

repo: snowleopard/shaking-up-ghc


text:
Missing documentation on config.hocon

While using --config option with config file, with JSON-like syntax you can't bind to, for example, environment variables, because .config file is not parsed like a hocon file. So, the code below won't work (variables won't be replaced)
{
  "input": {
    "queue": "${QueueUrl}"
  }

  "output": {

    # Configure output kinesis stream for valid messages
    "good": {
      "streamName": "${GoodStreamName}"
    }

    # Configure output kinesis stream for invalid messages
    "bad": {
      "streamName": "${BadStreamName}"
    }
  }
}

But it will work without a problem when you'll use regular hocon syntax like below (like here for example):
sqs2kinesis = {
  input = {
    queue = ${QueueUrl}
  }

  output = {

    # Configure output kinesis stream for valid messages
    good = {
      streamName = ${GoodStreamName}
    }

    # Configure output kinesis stream for invalid messages
    bad = {
      streamName = ${BadStreamName}
    }
  }
}

Hi @marcin-j I think the only problem with your top example is the quote marks around your environment variables.  It doesn't matter that it uses Json syntax.  For example, this is completely valid:
{
  "input": {
    "queue": ${QueueUrl}
  }

  "output": {

    # Configure output kinesis stream for valid messages
    "good": {
      "streamName": ${GoodStreamName}
    }

    # Configure output kinesis stream for invalid messages
    "bad": {
      "streamName": ${BadStreamName}
    }
  }
}

But you are right, we haven't documented this well.  My preference is to link to the hocon documentation here, rather than maintain our own version of the description.  So I will add a link there in the next release.

@istreeter you're right, thanks for clarification. That was my misunderstanding of hocon syntax

source: gharchive/issue

authors: istreeter marcin-j

license_type: permissive

license_source: github-api


text:
Redshift: add migration script for 0.5.0 to 0.7.0

This will save a lot of pain...

Looks like this can't be done without creating a new table because 0.6.0 changed mkt_clickid from varchar(64) to varchar(128).
http://stackoverflow.com/questions/17101918/alter-column-datatype-in-amazon-redshift

I think you're right...

authors: alexanderdean fblundun

repo: snowplow/snowplow

license_source: bigquery


text:
configurable url, use bypass for api-tests

make url configurable for api-tests with bypass lib,
timezone tests could not be fixed (also in doctest)

Hi there,
First, thank you for contributing! I really appreciate your efforts into it.
However, I do notice you have been experiencing issues getting the tests to work implementing this PR. Do you think it would be better to raise an issue with what you are encountering, and we can work out the details. Or would you like me to review this PR now?

@sntran Seems like the tests for this one are now passing. Any chance we could get this one merged?

Hi @nbw .
With the lack of communication from @ReneKl , it's hard for me to figure out what this PR does. I have spent some time looking through the changes, and here are a few concerns I have:

The PR is based on the dev branch, which switched to mint from httpoison. The PR then changed from mint back to httpoision. This is hard for me to merge.
Pardon my ignorance, but I don't fully understand the purpose of bypass. If you are to mock API response to your desired, then how the tests would correctly corresponding to actual API response? Yes, the tests will pass, but the library will fail if Google's response is difference.
The PR also commented out some tests that do not pass for itself. If the purpose of the PR is to provide more test cases, removing other test cases are not ideal.

source: gharchive/pull-request

authors: ReneKl nbw sntran

license: MIT


text:
Separate cmd file and fix some issue of alert

What this PR does / why we need it:
The reason of long time to trigger sync all api is that the task manager runs with api service. Both of them share green pool together. The task manager take many many green threads so that sync all api will be blocked to get green thread. some changes about the pr:

separate api, task, alert
fix some issue of alert service initialization.
fix unit test mock import error.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #180
Special notes for your reviewer:
Release note:

With this change , Do we need to start 3 process seprately?

yes, we can aslo include allinone.py if required.

repo: sodafoundation/SIM


text:
WIP: use system-deps to handle libsodium dependency

Breaking change as some old build env variables are now longer working:

re-implemented SODIUM_LIB_DIR assuming you want to keep it but only
tested on Linux.
removed SODIUM_SHARED as there is currently no way to statically link
to SODIUM_LIB_DIR. I can consider extending system-deps if you'd like to
keep this feature.

Fix #359

Our CI currently relies on static linking, you could add the required environment variables to enable that behavior to .github/workflows/default.yml, and you need to follow the instructions here so it's correctly passing them through to cross.
Reach out if you need help and I'd try to prepare a patch to do that. :)

Thanks @kpcyrd
I defined the proper env variable but I'm not sure about where to put this Cross.toml file?

Also, looks like Windows building is failing because it doesn't find the pkg-config file. Isn't it shipped with the windows lib?

Yeah our build.rs is a bit complicated. On linux we can take a system lib or build libsodium from source (if crosscompiling), on windows we can either link via a provided lib or take it from https://github.com/sodiumoxide/sodiumoxide/blob/master/libsodium-sys/build.rs#L324.

@gdesmott  Also take a look at https://github.com/sodiumoxide/sodiumoxide/issues/377

Nice progress. Now we are left with env vars https://github.com/sodiumoxide/sodiumoxide/blob/master/libsodium-sys/README.md (tested in https://github.com/sodiumoxide/sodiumoxide/blob/master/testcrate/build.rs).

Yeah I'm looking into it, it's a bit trickier than expected.

Need help?

Didn't had much time to investigate lately because of work.
The problem is with DEP_SODIUM_LIB. system-deps follow the pkg-config default and so does not return the lib dir when using the standard location. See this discussion for the rational of this change.
As a result I can't guarantee to have the libdir defined from pkg-config which makes things harder. We could of course re-pull the lib with PKG_CONFIG_ALLOW_SYSTEM_LIBS but it kinda defeat the purpose of using  system-deps. :\

I added some new API to system-deps to try solving this problem. It's not merged/released yet as I'd like to make sure it does the job before.
Looks like we have two issues left:

1.36 support. Would you consider bumping the minimum Rust version or should I try solving this in system-deps?
Windows test keep failing, I'm not sure why. I don't have the setup to reproduce it locally so some help would be welcome here @kpp

I added some new API to system-deps to try solving this problem. It's not merged/released yet as I'd like to make sure it does the job before.
Looks like we have two issues left:

1.36 support. Would you consider bumping the minimum Rust version or should I try solving this in system-deps?
Windows test keep failing, I'm not sure why. I don't have the setup to reproduce it locally so some help would be welcome here @kpp

Would you consider bumping the minimum Rust version

Yes

Would you consider bumping the minimum Rust version

Yes

Closing due to deprecation of the library.

authors: dnaq gdesmott kpcyrd kpp

repo: sodiumoxide/sodiumoxide


text:
Converting keras models to Caffe models

Hi
Sorry if the question is a little irrelevant, but I'm really stuck. How did you convert the keras models to Caffe models? Can you guide me to the right piece of code or converter? Thank you.

Sorry for the keras converter, I can't find the code.
There is no trick for me to convert a model for any source to caffe. I load the weight from the source model and write to the target caffe model based on an accurate deploy.prototxt. It requires patience and caution.

Hi
Where can I find the pre-trained caffemodel for inception-v4? I found the input size of inception-v4 is 299299, but my image set data is 256256, I don't have the space on my computer to convert it again. So could you please help me?

@zhujiapeng
You can find the download urls here https://github.com/soeaver/caffe-model/tree/master/cls.
And the input size problem please check https://github.com/soeaver/caffe-model/issues/11

@soeaver
蟹蟹!

authors: soeaver szm2015 zhujiapeng

repo: soeaver/caffe-model

license: mit


text:
Add Discovery Support for this Adapter

Hey,
please check out the Discovery-Adapter (https://github.com/ioBroker/ioBroker.discovery) and check if the device can be detected somehow (special url with defined answer, special port, upnp, udp or other technologies?!). If yes it would great if you could add a pull request to the Discovery-Adapter with the needed code.
Support needed? Contact me (Apollon77) in Forum as forum thread or PN ;-)
Ingo

Done.