Avoid moving cursor in complete_func. Closes #238

It's not needed when called from Vim (tested
with Ctrl-x Ctrl-o and double checked Vim's documentation,
it's not in complete-functions specifications), but it breaks
omnicompletion when called from deoplete.
With this fix Ensime completion can be configured as
g:deoplete#omni#input_patterns instead of
g:deoplete#omni_patterns. See 'FAQ' in deoplete
documentation to know more about the advantages.
Sample config:
let g:deoplete#omni#input_patterns = {}
let g:deoplete#omni#input_patterns.scala = '[^. *\t]\.\w*'

Please, before merging this, could you double-check that it works in neovim?

Hi @jvican I tested it in Neovim. My main motivation for fixing this is to be able to use ensime-vim completion with deoplete which is a neovim-only plugin.

Sorry, totally miss deoplete was neovim-only.
LGTM. This is all yours @ChrisCoffey.

@ChrisCoffey I know this is already closed, but would you be against contributions that automatically configure deoplete?

WDYM @Jacoby6000 ?

Would it be reasonable for ensime-vim to provide deoplete configuration?  Then, rather than people having to work out what completion patterns should be, it's just supported by ensime.

Yes, it would be reasonable! I guess that they should be pretty standard and improve the user experience. :smile:


[CMO] When "Clear Scan" is clicked on the summary page after scanning the shipment and individual kits, the screen shows Wrong Shipment Code screen

Upon Clear scan, the user should view the same screen as seen after Scan Shipment button click:
After this

We can see this:

But we should see this:

Clear Scan wrong Shipment Code screen rectified. Created PR for this


Models do not perform well for full range of outcomes

It looks like there is a sort of balancing issue. The following is an image on SIRUS 1.1.2, but the same occurs on 1.3.0:

It looks like the model optimizes for one area and not for another. I still suspect this is an issue with the choice of weights. Something is causing the weights to be not chosen properly which then causes sub-optimal classification predictions and poor regression predictions.

To solve this, I should probably set lambda because the weight logic is very sensitive to the choice of lambda.


Generating reference docs fails on linux

After trying the fix in #156, which got me past the error described there, I ran into this:
Missing method FSharp.MetadataFormat.AssemblyGroup::get_Namespaces() in assembly /home/liam/Code/fsharp/ProjectScaffold/packages/FSharp.Formatting/lib/net40/FSharp.MetadataFormat.dll, referenced in assembly data-0x48030d0
System.MissingMethodException: Method not found: 'FSharp.MetadataFormat.AssemblyGroup.get_Namespaces'.
  at RazorEngine.Templating.TemplateBase.RazorEngine.Templating.ITemplate.Run (RazorEngine.Templating.ExecuteContext context, System.IO.TextWriter reader) [0x00000] in <filename unknown>:0
  at RazorEngine.Templating.RazorEngineCore.RunTemplate (ICompiledTemplate template, System.IO.TextWriter writer, System.Object model, RazorEngine.Templating.DynamicViewBag viewBag) [0x00000] in <filename unknown>:0
  at RazorEngine.Templating.RazorEngineService.Run (ITemplateKey key, System.IO.TextWriter writer, System.Type modelType, System.Object model, RazorEngine.Templating.DynamicViewBag viewBag) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) RazorEngine.Templating.RazorEngineService:Run (RazorEngine.Templating.ITemplateKey,System.IO.TextWriter,System.Type,object,RazorEngine.Templating.DynamicViewBag)
  at RazorEngine.Templating.RazorEngineService.RunCompile (ITemplateKey key, System.IO.TextWriter writer, System.Type modelType, System.Object model, RazorEngine.Templating.DynamicViewBag viewBag) [0x00000] in <filename unknown>:0
  at RazorEngine.Templating.DynamicWrapperService.RunCompile (ITemplateKey key, System.IO.TextWriter writer, System.Type modelType, System.Object model, RazorEngine.Templating.DynamicViewBag viewBag) [0x00000] in <filename unknown>:0
  at RazorEngine.Templating.RazorEngineServiceExtensions.RunCompile (IRazorEngineService service, System.String name, System.IO.TextWriter writer, System.Type modelType, System.Object model, RazorEngine.Templating.DynamicViewBag viewBag) [0x00000] in <filename unknown>:0
  at RazorEngine.Templating.RazorEngineServiceExtensions+<>c__DisplayClass4.<RunCompile>b__3 (System.IO.TextWriter writer) [0x00000] in <filename unknown>:0
  at RazorEngine.Templating.RazorEngineServiceExtensions.WithWriter (System.Action`1 withWriter) [0x00000] in <filename unknown>:0
  at RazorEngine.Templating.RazorEngineServiceExtensions.RunCompile (IRazorEngineService service, System.String name, System.Type modelType, System.Object model, RazorEngine.Templating.DynamicViewBag viewBag) [0x00000] in <filename unknown>:0
  at <StartupCode$FSharp-MetadataFormat>.$Razor+ProcessFileModel@212[System.Collections.Generic.IDictionary`2[System.String,System.String]].Invoke (Microsoft.FSharp.Core.Unit _arg1) [0x00000] in <filename unknown>:0
  at FSharp.MetadataFormat.RazorRender.handleCompile[String] (System.String source, Microsoft.FSharp.Core.FSharpFunc`2 f) [0x00000] in <filename unknown>:0
Stopped due to error

At the "Generating Reference Documentation" step.
This is under Mono 3.2.8, FSharp 3.0 and nuget 2.8.60318.667
I'm not really sure how to debug it further, I'm only really just getting started with F#.

This looks you compile razor templates with a different version of FSharp.Formatting than what you are using at execution time. As normally you should get a TemplateCompilationException for such things. Have you multiple versions of FSharp.Formatting laying around? Is this a clean ProjectScaffold project? Do you have a repro?

It was a clean pull, I didn't change any code aside from the package version lock thing in #156.
I did have some issues pulling the packages (intermittent failures during download) but that shouldn't have resulted in multiple copies of the same package... right?
In any case, I'll try another pull and let you know if the same issue occurs.

It works fine with mono 4.0.2.


Improve view management

published as<EMAIL_ADDRESS>

I see the "Clear Storage". How do I make use of the browser storage? Do you want to added this to the demo.

The view locations are stored in the storage and shared between tabs. The clear storage button allows to come back to the default layout (after a refresh). Does it answer your question?

Demo: Put "Settings" and "Keybindings" side by side instead of below each other. Then you see both immediately when you hit "Toggle Panel"

I'm aware the demo is improvable, I try to improve it next time I touch it! :+1: thanks for the suggestion

The view locations are stored in the storage and shared between tabs. The clear storage button allows to come back to the default layout (after a refresh). Does it answer your question?

Yes, can this be observed with browser dev tools?

The view locations are stored in the storage and shared between tabs. The clear storage button allows to come back to the default layout (after a refresh). Does it answer your question?

Yes, can this be observed with browser dev tools?

Yes, in Application => Storage => IndexedDB


When clicked, file type field immediately says "This field is invalid"

We have the following code in our form:
<AvField
type="file"
id="file"
name="file"
label="File*"
required
onChange={e => {
this.setStateIfMounted({ file: e.target.files[0] })
}}
/>
When the user clicks on the field to choose a file, it immediately displays "This field is invalid" immediately below the field, as soon as the file dialog opens. While the error message is correct, it may be disconcerting for some users. We would prefer if it was only displayed if the user closes the dialog without selecting a file.

This is probably because the dialog causes the field to blur. We'd probably need to make a special case for file to only trigger touched when dialog closes (which I believe can be determined by onChange).


Fix rubecop constants-in-block

Description
This PR fixes Rubecop listing error caught by Sonatype Lift here.
Notes for Reviewers
Signed commits

[ ] Yes, I signed my commits.

🚀 Preview for commit d14b5f7cfa188730209950bf9bb15657eab06e89 at: https://61674e968f415e163625ba34--meshery-docs-preview.netlify.app


Enhance error handling in Table.add_index method

This commit introduces a try-except block in the Table.add_index method to gracefully handle exceptions when adding an index. If an error occurs, the index is dropped if it exists, and the exception is re-raised for further handling. This change improves the robustness of the indexing process and ensures that eviction warnings are emitted only when the index addition is successful.

This change is


Running all checks caused repository crash

We tried: Control Panel -> Checks -> Run all checks, but this took forever and crashed the repository. Maybe this option should be removed from the interface, or at least a note of caution should be included if many checks are selected.

@cyplas is it still reproducible?

It seems to be working fine now (even though we are still on v1.2).


Collection creation

Purpose
PR to add collection creation to the unity-py library
Proposed Changes

Added collection Creation method

Testing

added collection tests to test_unity_data_services.py
did testing in jupyter notebook pointing at unity-dev

coverage: 88.105% (+2.1%) from 86.041%
when pulling 4f1a9527a797ea807df49209e616093fed13d8d1 on collection-creation
into b005f564fee62aa726d55a6461f7f4c612860069 on develop.


context options for mount are not being applied

const context = { name: "foo", id: 1};

  const wrapper = mount(<MyComponent />, {
    context,
    childContextTypes: { name: PropTypes.string, id: PropTypes.number }
  });

  expect(wrapper.context().name).toBe("foo");

The default context values were initialised as follows:
const MyContext = React.createContext({ id: 0, name: "" });

Current behavior
The test is failing, with the following errors:
expect(received).toBe(expected) // Object.is equality

    Expected: "foo"
    Received: ""

      22 |   });
      23 |
    > 24 |   expect(wrapper.context().name).toBe("foo");
         |                                  ^

      at Object.toBe (src/App.test.js:24:34)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total

Expected behavior
I expect the value of name to be "foo".
Your environment
"dependencies": {
    "react": "^16.7.0",
    "react-dom": "^16.7.0",
    "react-scripts": "2.1.2"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": [
    ">0.2%",
    "not dead",
    "not ie <= 11",
    "not op_mini all"
  ],
  "devDependencies": {
    "enzyme": "^3.8.0",
    "enzyme-adapter-react-16": "^1.7.1"
  }

API

[ ] shallow
[x] mount
[ ] render

Adapter

[x] enzyme-adapter-react-16
[ ] enzyme-adapter-react-16.3
[ ] enzyme-adapter-react-16.2
[ ] enzyme-adapter-react-16.1
[ ] enzyme-adapter-react-15
[ ] enzyme-adapter-react-15.4
[ ] enzyme-adapter-react-14
[ ] enzyme-adapter-react-13
[ ] enzyme-adapter-react-helper
[ ] others ( )

enzyme does not yet support createContext. See #1553.


Form - labels - block/inline per breakpoint + mobile first styles

new idea:
.label-xs-block
.label-lg-inline

another solution
.label.xs-block
.label.lg-inline

implemented in https://github.com/Foreveryone-cz/LUI-2/commit/0a5a146bf9eb480272f2cfbc34049f98e39b8adf


wip: doc for WedderburnDecomposition

@thinh-le thanks for writing this up!
I fixed a few things and expanded others. When writing about other packages it's best to be very careful ;)
@blegat could you have a look and comment?


runtime: memory leaked observed in go program

What version of Go are you using (go version)?

go1.14.3

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=arm
set GOBIN=
set GOCACHE=C:\Users\irhpoq\AppData\Local\go-build
set GOENV=C:\Users\irhpoq\AppData\Roaming\go\env
set GOEXE=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=linux
set GOPATH=D:\Karthik\Skills\Golang\GolangTraining-master
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set GOARM=7
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-fPIC -marm -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\irhpoq\AppData\Local\Temp\go-build018000050=/tmp/go-build -gno-record-gcc-switches

What did you do?

What did you expect to see?
RSS memory should not keep increasing
What did you see instead?
RSS memory was keep increasing. It increased from 4472 KB to 4648 KB in 15 mins
temp_sensor.txt

after 20 mins

Both TCP server and temp_sensor RSS(RAM) memory is keep growing

From what I can see in that program, you're making new goroutines without ever exiting them.
go autoTempUpdate(Msg1)

That goroutine never exits. And you're making one of them for every request handled.
Is this the same bug as #40404 ?

yeah that is what the intention also, we dont want to exit the go routine, each goroutine should update the temp for every 10 secs indefinitely  or until we close the program. Yeah I am the one who logged that bug also, Actually this is my main program, I see the more memory leak here so I just created simple tcp client program where it would send the message to TCP server every 10 sec continuously, there also i could see memory leak. so I logged that bug. Here when there is 2 or more gorouine created more memory leak was observed

Actually I am preferring go lang as other scripting language like python, ruby is taking more RAM memory as compared to golang, but here i could see memory leak, Please help me to resolve this issue

You keep making new goroutines that never exit. Each one uses some memory. That's your leak.
You need to exit the goroutines at some point.

Even I have C program where multiple threads running which will never exit, and I dont see any memory leaking. So in GO we cant create any thread which should always. In all real time application, we wanted to have thread which should run indefinitely right, I understand each go routine would use additional 4KB of memory when we create new go routine, After I created 6 go routine it can take around 24KB extra, but why it keeps growing. moreover In each go routine I am just sending message to TCP server nothing else i am doing, but I dont understand why memory is keep growing.

I understand each go routine would use additional 4KB of memory when we create new go routine, After I created 6 go routine it can take around 24KB extra, but why it keeps growing.
Because you're not creating just 6 goroutines. You're making a new one with each call to webRequestHandler.

yeah I have just made 5 http request and observed that whether 5 goroutine was created or not, I saw 5 goroutine was created  and I have not made any web request after that. whatever memory leak that I shared is with 5 goroutine only

I am attaching sample output for you,
Message Received: "temperature 1823R5BNAX: 32820", size:30
Message Received: "temperature 1823R2BNAX: 32780", size:30
Message Received: "temperature 1823R4BNAX: 32790", size:30
Message Received: "temperature Sensor1: 32870", size:30
Message Received: "temperature Sensor2: 32790", size:30
Message Received: "temperature Sensor3: 32830", size:30
Message Received: "temperature Sensor4: 32790", size:30
Message Received: "temperature Sensor5: 32800", size:30
Message Received: "temperature Sensor1: 32880", size:30
Message Received: "temperature Sensor2: 32800", size:30
Message Received: "temperature Sensor3: 32840", size:30
Message Received: "temperature Sensor4: 32800", size:30
Message Received: "temperature Sensor5: 32810", size:30
Message Received: "temperature Sensor1: 32890", size:30
Message Received: "temperature Sensor2: 32810", size:30
Message Received: "temperature Sensor3: 32850", size:30
Message Received: "temperature Sensor4: 32810", size:30
Message Received: "temperature Sensor5: 32820", size:30
Message Received: "temperature Sensor1: 32900", size:30
Message Received: "temperature Sensor2: 32820", size:30
Message Received: "temperature Sensor3: 32860", size:30
Message Received: "temperature Sensor4: 32820", size:30
Message Received: "temperature Sensor5: 32830", size:30
Message Received: "temperature Sensor1: 32910", size:30
Message Received: "temperature Sensor2: 32830", size:30
Message Received: "temperature Sensor3: 32870", size:30
Message Received: "temperature Sensor4: 32830", size:30
Message Received: "temperature Sensor5: 32840", size:30
Message Received: "temperature Sensor1: 32920", size:30
Message Received: "temperature Sensor2: 32840", size:30
Message Received: "temperature Sensor3: 32880", size:30
Message Received: "temperature Sensor4: 32840", size:30
Message Received: "temperature Sensor5: 32850", size:30

Now it is increased to 1MB in 1 hour from 4488KB to 5368KB

This all observation with 5 goroutine only

Ok, then we're going to need more instructions about how exactly you exercised your binaries, so we can recreate the problem.
You've included the temp_sensor binary here. I got the server code from the other issue. Which version are you using? Are those the codes in question? How did you run them? How did you send them requests?

Is this as duplicate of https://github.com/golang/go/issues/40404?

@randall77 Sure I will share you whatever help that you need from my side. I am attaching the tcp_server code that i used,
tcp_server.txt
I am using "go1.14.3", Is there any other version of GOLang which does not have this problem

Steps to run the program:

Run "tcp_server.go" first,
Then run "temp_sensor.go" program,
Thirdly, we need to send http post request with Json message to the machine where "temp_sensor.go" is running,
You can use "Linux CURL" command to send the http POST request.

Command
curl -X POST -d "{"Sensor" : "Sensor1"}" http://<IP_ADDRESS>:8080
curl -X POST -d "{"Sensor" : "Sensor2"}" http://<IP_ADDRESS>:8080
curl -X POST -d "{"Sensor" : "Sensor3"}" http://<IP_ADDRESS>:8080
curl -X POST -d "{"Sensor" : "Sensor4"}" http://<IP_ADDRESS>:8080
curl -X POST -d "{"Sensor" : "Sensor5"}" http://<IP_ADDRESS>:8080
This would create 5 threads  temp_sensor.go program, each would be parallelly sending temp value to tcp_server.go program.

@santhoshkarthi once your program has leaked will you please send SIGQUIT to it; you can do this with the command
kill -QUIT $PID

where $PID is the process id of your server program. This will dump a large amount of information, please include all of it.

Below is the Embedded Linux board RAM memory,It was taken when we started the "temp_sensor.go" and "tcp_server.go" binary,

Below image was taken after 1 hour,

If you see RAM memory of temp sensor was increased almost 1MB in 1 hr, and still it keep growing and it is not cleared the memory

@santhoshkarthi to reiterate what @randall77 has said earlier. Your program has a number of places where goroutines can leak, this will cost at least 2kb per goroutine leaked. The procedure I outlined above will confirm our hypothesis.

@davecheney When we kill -QUIT $PID, it will kill the process right, will it generate any file, I just tried it for another process, before doing it to "temp_sensor" but It didnot throw any information in the console

Just wanted to confirm before trying it out in temp_sensor.go program

It is also important to remember that the design of the go garbage collector is not to release every byte of memory back to the operating system, this is by design and also a constraint -- linux simply does not have a way to tell the operating system to take a page of memory back, we can only ask it too take the memory back, and depending on the memory pressure of the system, the operating system often ignores that request.
I am telling you this because it is expected that Go processes can grow after they start, what we are investigating is they should not grow continually
.

@davecheney When we kill -QUIT $PID, it will kill the process right, will it generate any file, I just tried it for another process, before doing it to "temp_sensor" but It didnot throw any information in the console

This is a facility of the Go runtime, non Go programs may not respond to this signal.

@davecheney Yeah even I understand that, when goroutine is created it take some memory say 4KB for each goroutine is what I read, I have created 5 goroutine, so it can take around 20KB extra, even 100KB is fine, but what i am not able to understand is, why It keeps growing?

The thesis is your application is leaking goroutines, how many cannot be said without the information I asked for.

@davecheney I tried executing kill command for temp_sensor.go, but it didnot throw any message in the console,
kill -QUIT 30650(temp_sensor PID)

Do I need to export anything before running the go program

you do not need to export anything

Now I got it, after I export "export GODEBUG=gctrace=1"
`SIGQUIT: quit
PC=0x727cc m=0 sigcode=0
goroutine 0 [idle]:
runtime.futex(0x4bad84, 0x80, 0x0, 0x0, 0x0, 0x0, 0x19501, 0x197b8, 0x1999c, 0x49648, ...)
c:/go/src/runtime/sys_linux_arm.s:415 +0x1c
runtime.futexsleep(0x4bad84, 0x0, 0xffffffff, 0xffffffff)
c:/go/src/runtime/os_linux.go:45 +0x70
runtime.notesleep(0x4bad84)
c:/go/src/runtime/lock_futex.go:151 +0xac
runtime.stopm()
c:/go/src/runtime/proc.go:1828 +0xa4
runtime.findrunnable(0x101a000, 0x0)
c:/go/src/runtime/proc.go:2360 +0x618
runtime.schedule()
c:/go/src/runtime/proc.go:2520 +0x2c8
runtime.park_m(0x1000ee0)
c:/go/src/runtime/proc.go:2690 +0x80
runtime.mcall(0x6f988)
c:/go/src/runtime/asm_arm.s:285 +0x5c
goroutine 1 [select (no cases)]:
main.main()
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:87 +0xc4
goroutine 6 [chan receive]:
main.Thread()
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:67 +0xc8
created by main.main
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:81 +0xac
goroutine 7 [IO wait]:
internal/poll.runtime_pollWait(0x66c40f30, 0x72, 0x0)
c:/go/src/runtime/netpoll.go:203 +0x44
internal/poll.(*pollDesc).wait(0x106e1a4, 0x72, 0x0, 0x0, 0x2a6dac)
c:/go/src/internal/poll/fd_poll_runtime.go:87 +0x30
internal/poll.(*pollDesc).waitRead(...)
c:/go/src/internal/poll/fd_poll_runtime.go:92
internal/poll.(*FD).Accept(0x106e190, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
c:/go/src/internal/poll/fd_unix.go:384 +0x1b0
net.(*netFD).accept(0x106e190, 0x3, 0x4ba638, 0x1042148)
c:/go/src/net/fd_unix.go:238 +0x20
net.(*TCPListener).accept(0x100e120, 0x106c640, 0x20f9e100, 0x4d608)
c:/go/src/net/tcpsock_posix.go:139 +0x20
net.(*TCPListener).Accept(0x100e120, 0x1024f1c, 0xc, 0x1000fc0, 0x21a220)
c:/go/src/net/tcpsock.go:261 +0x54
net/http.(*Server).Serve(0x1060510, 0x30f690, 0x100e120, 0x0, 0x0)
c:/go/src/net/http/server.go:2901 +0x1fc
net/http.(*Server).ListenAndServe(0x1060510, 0x1060510, 0x1)
c:/go/src/net/http/server.go:2830 +0xa0
net/http.ListenAndServe(...)
c:/go/src/net/http/server.go:3086
main.webHandlerThread()
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:75 +0xc8
created by main.main
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:82 +0xc0
goroutine 10 [sleep]:
time.Sleep(0x540be400, 0x2)
c:/go/src/runtime/time.go:188 +0xec
main.autoTempUpdate(0x10143b0, 0x7)
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:39 +0x1b8
created by main.webRequestHandler
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:52 +0x110
goroutine 13 [sleep]:
time.Sleep(0x540be400, 0x2)
c:/go/src/runtime/time.go:188 +0xec
main.autoTempUpdate(0x1014458, 0x7)
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:39 +0x1b8
created by main.webRequestHandler
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:52 +0x110
goroutine 16 [sleep]:
time.Sleep(0x540be400, 0x2)
c:/go/src/runtime/time.go:188 +0xec
main.autoTempUpdate(0x10144b8, 0x7)
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:39 +0x1b8
created by main.webRequestHandler
D:/Karthik/Skills/Golang/GolangTraining-master/karthik/zwave_simulator/temp_sensor.go:52 +0x110
trap    0x0
error   0x0
oldmask 0x0
r0      0x4bad84
r1      0x80
r2      0x0
r3      0x0
r4      0x0
r5      0x0
r6      0x2c287
r7      0xf0
r8      0x7
r9      0x3
r10     0x4baac8
fp      0x7
ip      0x1
sp      0x7e88cbfc
lr      0x3f8f0
pc      0x727cc
cpsr    0x20000010
fault   0x0
`

Now I got it after I export "export GODEBUG=gctrace=1"
`Message was sent to server...
Message was sent to server...
Message was sent to server...
Message was sent to server...
SIGQUIT: quit
PC=0x727cc m=0 sigcode=0
goroutine 0 [idle]:
runtime.futex(0x4bad84, 0x80, 0x0, 0x0, 0x0, 0x0, 0x19501, 0x197b8, 0x1999c, 0x49648, ...)
c:/go/src/runtime/sys_linux_arm.s:415 +0x1c
runtime.futexsleep(0x4bad84, 0x0, 0xffffffff, 0xffffffff)
c:/go/src/runtime/os_linux.go:45 +0x70
runtime.notesleep(0x4bad84)
c:/go/src/runtime/lock_futex.go:151 +0xac
runtime.stopm()
c:/go/src/runtime/proc.go:1828 +0xa4
runtime.findrunnable(0x101a000, 0x0)
c:/go/src/runtime/proc.go:2360 +0x618
runtime.schedule()
c:/go/src/runtime/proc.go:2520 +0x2c8
runtime.park_m(0x1000ee0)
c:/go/src/runtime/proc.go:2690 +0x80
runtime.mcall(0x6f988)
c:/go/src/runtime/asm_arm.s:285 +0x5c
goroutine 1 [select (no cases)]:
main.main()
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:87 +0xc4
goroutine 6 [chan receive]:
main.Thread()
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:67 +0xc8
created by main.main
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:81 +0xac
goroutine 7 [IO wait]:
internal/poll.runtime_pollWait(0x66c40f30, 0x72, 0x0)
c:/go/src/runtime/netpoll.go:203 +0x44
internal/poll.(*pollDesc).wait(0x106e1a4, 0x72, 0x0, 0x0, 0x2a6dac)
c:/go/src/internal/poll/fd_poll_runtime.go:87 +0x30
internal/poll.(*pollDesc).waitRead(...)
c:/go/src/internal/poll/fd_poll_runtime.go:92
internal/poll.(*FD).Accept(0x106e190, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
c:/go/src/internal/poll/fd_unix.go:384 +0x1b0
net.(*netFD).accept(0x106e190, 0x3, 0x4ba638, 0x1042148)
c:/go/src/net/fd_unix.go:238 +0x20
net.(*TCPListener).accept(0x100e120, 0x106c640, 0x20f9e100, 0x4d608)
c:/go/src/net/tcpsock_posix.go:139 +0x20
net.(*TCPListener).Accept(0x100e120, 0x1024f1c, 0xc, 0x1000fc0, 0x21a220)
c:/go/src/net/tcpsock.go:261 +0x54
net/http.(*Server).Serve(0x1060510, 0x30f690, 0x100e120, 0x0, 0x0)
c:/go/src/net/http/server.go:2901 +0x1fc
net/http.(*Server).ListenAndServe(0x1060510, 0x1060510, 0x1)
c:/go/src/net/http/server.go:2830 +0xa0
net/http.ListenAndServe(...)
c:/go/src/net/http/server.go:3086
main.webHandlerThread()
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:75 +0xc8
created by main.main
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:82 +0xc0
goroutine 10 [sleep]:
time.Sleep(0x540be400, 0x2)
c:/go/src/runtime/time.go:188 +0xec
main.autoTempUpdate(0x10143b0, 0x7)
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:39 +0x1b8
created by main.webRequestHandler
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:52 +0x110
goroutine 13 [sleep]:
time.Sleep(0x540be400, 0x2)
c:/go/src/runtime/time.go:188 +0xec
main.autoTempUpdate(0x1014458, 0x7)
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:39 +0x1b8
created by main.webRequestHandler
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:52 +0x110
goroutine 16 [sleep]:
time.Sleep(0x540be400, 0x2)
c:/go/src/runtime/time.go:188 +0xec
main.autoTempUpdate(0x10144b8, 0x7)
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:39 +0x1b8
created by main.webRequestHandler
D:/local_disk/Skills/Golang/GolangTraining-master/code/temp_sensor/temp_sensor.go:52 +0x110
trap    0x0
error   0x0
oldmask 0x0
r0      0x4bad84
r1      0x80
r2      0x0
r3      0x0
r4      0x0
r5      0x0
r6      0x2c287
r7      0xf0
r8      0x7
r9      0x3
r10     0x4baac8
fp      0x7
ip      0x1
sp      0x7e88cbfc
lr      0x3f8f0
pc      0x727cc
cpsr    0x20000010
fault   0x0
`

@davecheney Is this what you are asking

temp_sensor_debug_output.txt
@davecheney I put the details in txt file

yes, that is correct. This process shows three autoTempUpdate goroutines running. Can you please repeat this process once you feel the process has leaked sufficiently.

yeah now I have created 3 threads, just to share the debug output. Sure I will repeat the process and share the output
Thanks @davecheney

@davecheney @randall77
As you said I rerun my temp_sensor program, RSS memory was grew up to 5228KB from 4000KB, in 2hrs. and it keeps growing, never come down, only 5 goroutine were created.
Attaching debug outputs
temp_sensor_debug_output_with_5threads.txt

Did you get chance to run this code/program from your end, Just wanted to understand whether did you see the memory issue

Ok, the next thing is to get the GODEBUG output working.  How would i get the debug output

THis is the memory details when I am starting the temp_sensor and tcp_server

root@ccimx6ulsbc:/home/root# env GODEBUG=gctrace=1 ./temp_sensor
Entered into main
Entered into webHandler Thread...
Entered into main Thread...
I executed as you said

@davecheney So far there is no debug output printed in the console

@davecheney  there was no debug message printed after I ran "env GODEBUG=gctrace=1 ./temp_sensor" this. Please let me know if i missed anything

@randall77 , I have shared all the codes and steps to run the program,
https://github.com/golang/go/issues/40448#issuecomment-665537758
Please let me know whether you are able to observe the memory leak issue

@davecheney there was no debug message printed after I ran "env GODEBUG=gctrace=1 ./temp_sensor" this. Please let me know if i missed anything

That is the correct command, I cannot explain why it has not output any information.

Ok, I can reproduce, sort of.
The RSS is indeed slowly growing. But the Go heap is really small. In Go's default configuration we don't run our first GC until the heap is close to 4MB. On OSX, the RSS (which is the Go heap, plus lots of other stuff) starts at ~1.9MB and grows very slowly (~100B/sec). So it will take many hours to reach the point at which we do our first GC.
So you're just seeing the GC being very relaxed about collecting small heaps. It's just very slowly paging in the minimum heap as needed, 4KB every minute or so. If you let it run long enough, it should collect that memory, return it to the OS, and repeat. If you're more patient than me, you could let it run for a day or two and see.
We used to run a GC every few minutes. I don't think we do that any more. @mknyszek , do you know?

@randall77 We do still force a GC every 2 minutes, unless the GC is turned off (GOGC=0 or SetGCPercent(-1)). Based on this thread, it doesn't look like the program is being invoked with GOGC as an environment variable, so is it possible SetGCPercent is getting called? That would explain why there's no gctrace output, since it's printed at the end of a GC.
@santhoshkarthi Do you call SetGCPercent(-1) at any point in your program? If not, do any of your dependencies call it?

I can't seem to get the GC to trigger for this case. There's no GOGC or SetGCPercent.
The code spends most of its time sleeping. Would that matter?
Here's a simple test case that behaves similarly to OP's code:
package main

import (
	"fmt"
	"time"
)

func main() {
	for n := 0; true; n++ {
		time.Sleep(time.Second)
		fmt.Printf("%d\n", n)
		sink = make([]byte, 1024)
	}
}

var sink []byte

It's allocating 1K/sec, and well after 2 minutes there's still no GC.
> go build tmp1.go
> GODEBUG=gctrace=1 ./tmp1
0
1
2
...
262
263

No gctrace output.
If I allocate 1MB instead of 1KB, I get a gc trace output every ~3-4 seconds, as expected.

I took another look at the logic, looks like we won't trigger a GC every two minutes if there hasn't been one yet... (return lastgc != 0 && t.now-lastgc > forcegcperiod). Given that, adding a runtime.GC() call at the beginning of main is one possible workaround to making sure it's on. This is a bug that should probably be fixed?
@santhoshkarthi Keith pointed out that the really slow rate of allocation means a GC might not be triggered for hours. The runtime has a minimum heap size of 4 MiB (note that RSS will be larger than that because this is just the allocated heap, not space for metadata, stacks, etc.). Even an RSS of 5228 KiB might not reflect a 4 MiB heap.

@mknyszek: Thanks. That workaround (adding runtime.GC() to the start of main) works for the OP's example.
The behavior is not perfect; it uses a few hundred KB to actually run a GC, and even after the first "real" GC the RSS increases somewhat. But it does look to plateau after the first few GCs.
Yes, not doing periodic GCs unless one has run already looks like something we should fix. As there is an easy workaround, maybe this is just a 1.16 thing.

@davecheney https://github.com/golang/go/issues/40448#issuecomment-665952463,
I have tried with other go programs, I didnot see any other messages printed other than the messages in the code,

Is there anything I need to add it in the code

I think, based on the responses above that output will be eventually printed by you will have to wait for at least 4mb of memory to be allocated on the heap.
Based on the responses above I don’t think this is a useful line of investigation. It is likely that, when observed from outside, your programs rss will grow by at least 4mb before stabilising.

@randall77 @mknyszek @davecheney Actually we are doing development in C and ruby, Since ruby is using more RAM we are trying to explore is there anyother language which would use less RAM at the same time it should have more libraries so that it would be easy for the development, So we tried exploring golang as it has lot of library support, and using less RAM memory compared to other scripting language like python and ruby, Our application development in Embedded board where RAM is limited to 256 MB RAM.
But if you see other Program like C it would use less RAM and it would not grow, where as if we take ruby and python taking more RAM memory but when come to memory leak, ruby and python also very stable, RAM is not increasing even after we ran the code code 1 or 2 days, where as Golang is using less RAM memory compared to other scripting language like ruby, Python, But the thing that is more concern is, RAM memory is keep increasing, Yeah you are saying that it would clear the RAM memory only heap reaches to 4MB, but in the embedded this 4MB is huge as we have 10 to 12 such application is running and RAM memory is limited to 256MB,
and one more thing that I still understand is, why heap memory is keep growing, when we dont create any dynamic memory during every iteration. we are just creating one thread and sending message to tcp server. and this is not happening in other language like C, ruby, Python.
Yesterday I just created only one thread, instead of 5 threads, and sending message to tcp_server every 10 secs,  that itself has memory leak.
When I start, Go program has 4336KB RAM and 524 as Dirty memory,

After I kept the board idle for one day, RAM memory went  to 5692 KB, and 1816 as a Dirty memory.

Please suggest me is there other lower go version does not have this memory leak, Because keep increasing this RAM memory with only one thread is more concern for us, As I told earlier, our embedded board RAM memory is limited to 256 MB

@davecheney @randall77 @mknyszek Please help me what I have to do to stop this memory leak

@santhoshkarthi as far as we know there is no memory leak. What you are seeing is the interaction of the operating system lazily allocating pages to the process as it touches them. We believe that once the program heap reaches the 4mb range the process size will stabilise; perhaps around the 7.8 to 9mb mark as measured by top.
I believe that you can verify this by reducing any delays or time.Sleeps in your program so that operations are performed more frequently. If I am correct then the observed RSS will grow faster and after it passes ~4mb over the base process size, somewhere between 7 and 9mb you should see an output from the GODEBUG=gctrace=1 debugging information indicating a GC cycle has occured. At that time the majority of the heap should be freed -- look for the output for something like this 4->4->0 which suggests the heap usage drops from 4mb to less than 1mb.
It is very likely that after the GC cycle has occured there will be only a small impact on RSS, possibly none at all. This is because the operating system will ignore the madvise(1) messages we send it until there is sufficient memory preasure (ie, the whole system is running low on ram).
Please try and let us know what you see.

@davecheney So you are saying that even single thread go program would use 9MB  of RAM, Our main intention of moving to GO from ruby is, RAM usage,  as ruby was using more RAM(close to 8.5MB), Now when you say 9MB, then both scripting(ruby) and GO is taking more or less same amount of RAM.
Is it possible to reduce the heap usage from 4MB to somewhat 2MB or less

The current minimum heap size of a Go program is 4mb. In addition to this the operating system threads that back goroutines should be added to that as well as some non heap memory used by the runtime. In your case this may be somewhere between 7 and 9mb.
Please remember that RSS is not how much memory is my program using, it is the resident segment size. Many things influence the value reported in RSS including the availability of swap and how much of the process may be swapped, if the system has reclaimed pages which we have madvise(DONTNEED) as part of the scavenger. A high RSS value does not necessarily mean that memory is not available for other processes, and so on.
If memory consumption is your primary objective I would suggest investigating https://tinygo.org/ who may (I cannot confirm) have a different approach to memory allocation.
I'll defer to @randall77 and @mknyszek on the question of if the minimum heap size can be reduced.

With @mknyszek's fix (adding a runtime.GC call to the start of main), you should not have to wait until you use 4MB to have GC run. It will run every 2 minutes. That should keep the heap size well below 4MB in this example.
We should be able to fix the need for that call in 1.16.
As far as lowering the minimum heap size, I suppose that's possible but I'd want to understand whether the above fix would be enough first. Ideally with the above fix, the 4MB is just virtual memory, not real memory.

have tried with other go programs, I did not see any other messages printed other than the messages in the code,

Try my example, but allocate 1MB instead of 1KB. You should see GC reports.

and one more thing that I still understand is, why heap memory is keep growing, when we dont create any dynamic memory

I suspect the allocations you're seeing are from the fmt package. You can check for sure by collecting a heap profile.

@davecheney I have gone through the link that you shared(https://tinygo.org/) but it looks like it is for microcontroller, ours is a microprocessor,(imx6-ARM7) and we are running linux-4.9, So the process wise we can run many process, even go application it does not seems to be heavy process(as I could see 0% CPU utilization most of the time). If memory is stable, definitely, It would be really great.
But in the internet if we go thorough how to get the actual RAM memory for each process, they say RSS(ps -l) or cat /proc/$PID/status

@randall77 As you said,  I added "runtime.GC()" in my main program, and I could see "gc" is getting triggered but it did not clear any memory,
`gc 2 @120.558s 0%: 0.11+7.4+0.12 ms clock, 0.11+0/1.5/5.6+0.12 ms cpu, 0->0->0 MB, 4 MB goal, 1 P
GC forced
gc 11 @1200.949s 0%: 0.11+14+0.31 ms clock, 0.11+0/3.6/10+0.31 ms cpu, 0->0->0 MB, 4 MB goal, 1 P
GC forced
gc 15 @1681.120s 0%: 0.11+7.0+0.11 ms clock, 0.11+0/1.2/5.6+0.11 ms cpu, 0->0->0 MB, 4 MB goal, 1 P
GC forced
gc 27 @3121.646s 0%: 0.11+18+0.12 ms clock, 0.11+0/6.2/11+0.12 ms cpu, 0->0->0 MB, 4 MB goal, 1 P`
Is it possible to decrease the heap memory threshold from 4MB to 1MB something.
and another question, Is there way to clear/flush the memory after we can fmt.Sprintf if this is what increasing the RAM memory.
Or is there anyother format string function which does not use fmt package so that my program RAM memory would not grow.

It would be great and I would really appreciate, if you guys can tell me way to make my Go program stable without Program RAM memory getting increased over that time like what other language does Eg, C, Ruby, Python.
@davecheney @randall77 @mknyszek
Thanks in advance

We have many applications in C and ruby running in our Embedded linux board, I dont see any RSS or RAM memory getting increased even after couple of days, It always shows the same amount of RAM(RSS) memory.

@randall77 As you said, I added "runtime.GC()" in my main program, and I could see "gc" is getting triggered but it did not clear any memory

How did you determine that it "did not clear any memory"?  Not sure how we round) and not growing.

Is it possible to decrease the heap memory threshold from 4MB to 1MB something.

You can try setting GOGC to a value less than 100. I think setting it to 10 should give you a 400KB heap. (It's an environment variable, or you can set it at the start of main with runtime/debug.SetGCPercent.)

and another question, Is there way to clear/flush the memory after we can fmt.Sprintf if this is what increasing the RAM memory.

You can call runtime.GC to run the garbage collector more often, and runtime/debug.FreeOSMemory to accelerate the pace of returning unused pages to the OS. Note that they are both expensive operations, you probably don't want to call them after every print.

Or is there anyother format string function which does not use fmt package so that my program RAM memory would not grow.

I don't know of one. You could write your own.
Your program also uses the json and net packages, which may contain allocations. Go is not really set up to achieve 0 allocations. It's certainly possible, but the stdlib is not designed that way, so you'd need to roll your own ~everything.

@randall77  Yeah it clears out RAM memory after it reaches to some 6MB, I think when we add runtime.GC in our code, it gets triggered every 10 sec I guess, Is there way in which we can specify the time interval at which "GC" will get triggered. Basically I dont want to be called for every 10 sec or too frequently.
Probably I will run the code for long run without having runtime.GC(), and see how much of RAM it uses and how much it had grown from the start of the program.
Thanks alot for your support


no dry-run option for npm

there's no way to dry-run publish npm packages, as this options is available in publib-npm

as to my knowledge this had been reverted, so this should be opened up again.

As a workaround, I have found you can set the env var npm_config_dry_run=true to convince npm to make a dry run.


When trying to parse something like
import 'foo' as Foo exposing { foo }
import 'foo/bar' as Foo.Bar
import 'foo/bar/baz' exposing { baz }

...

The parser will fail with the following error:
Err [{ col = 1, problem = ExpectingEnd, row = 3 }]

For whatever reason, the parser is skipping straight to checking if it's the end of the file for some reason.

This seems to be fixed now, spooky 👻.


Auto Storage?

I'm testing out simpleStorage.
I see you have a timer for length of time to persist.
I am wondering if an automated storing option to this software, might be more appropriate.
Example:  Local Storage allows you to set an interval option to auto store.  How might I do that with simpleStorage to accomplish the same thing, basically an auto store of a data/js var with simpleStorage js?
Maybe an addition?  Or needed feature?

No worries, built my own.  Cheers!  And thanks for the cool code! =)


dbt run --select "dbt_project_evaluator.*" fails when run against an empty dataset.

Describe the bug
dbt run --select "dbt_project_evaluator.*" fails when run against a newly-created dataset.
Steps to reproduce

create a new schema, and configure profiles.yml to target that dataset
dbt run --select "dbt_project_evaluator.*" --target <the target described in step 1>

Expected results
Successful completion of the run without any errors.
Actual results
It appears that 18 of the 33 models fail to build due to the dbt_project_evaluator_exceptions table being missing.
Screenshots and log output
dbt run --full-refresh --select "dbt_project_evaluator.*"
15:29:16  Running with dbt=1.2.2
15:29:17  Unable to do partial parsing because profile has changed
15:29:20  Found 212 models, 82 tests, 2 snapshots, 0 analyses, 873 macros, 0 operations, 10 seed files, 105 sources, 2 exposures, 21 metrics
15:29:20
15:29:23  Concurrency: 4 threads (target='dev')
15:29:23
15:29:23  4 of 33 START view model dbt_project_evaluator_test.stg_metrics ................ [RUN]
15:29:23  3 of 33 START view model dbt_project_evaluator_test.stg_metric_relationships ... [RUN]
15:29:23  1 of 33 START view model dbt_project_evaluator_test.stg_exposure_relationships . [RUN]
15:29:23  2 of 33 START view model dbt_project_evaluator_test.stg_exposures .............. [RUN]
15:29:24  3 of 33 OK created view model dbt_project_evaluator_test.stg_metric_relationships  [OK in 0.93s]
15:29:24  5 of 33 START view model dbt_project_evaluator_test.stg_naming_convention_folders  [RUN]
15:29:24  2 of 33 OK created view model dbt_project_evaluator_test.stg_exposures ......... [OK in 0.96s]
15:29:24  6 of 33 START view model dbt_project_evaluator_test.stg_naming_convention_prefixes  [RUN]
15:29:24  1 of 33 OK created view model dbt_project_evaluator_test.stg_exposure_relationships  [OK in 1.10s]
15:29:24  7 of 33 START table model dbt_project_evaluator_test.stg_node_relationships .... [RUN]
15:29:24  4 of 33 OK created view model dbt_project_evaluator_test.stg_metrics ........... [OK in 1.22s]
15:29:24  8 of 33 START table model dbt_project_evaluator_test.stg_nodes ................. [RUN]
15:29:25  5 of 33 OK created view model dbt_project_evaluator_test.stg_naming_convention_folders  [OK in 0.95s]
15:29:25  9 of 33 START view model dbt_project_evaluator_test.stg_sources ................ [RUN]
15:29:25  6 of 33 OK created view model dbt_project_evaluator_test.stg_naming_convention_prefixes  [OK in 1.12s]
15:29:26  9 of 33 OK created view model dbt_project_evaluator_test.stg_sources ........... [OK in 1.45s]
15:29:27  7 of 33 OK created table model dbt_project_evaluator_test.stg_node_relationships  [CREATE TABLE (410.0 rows, 0 processed) in 3.01s]
15:29:28  8 of 33 OK created table model dbt_project_evaluator_test.stg_nodes ............ [CREATE TABLE (306.0 rows, 0 processed) in 4.18s]
15:29:28  10 of 33 START table model dbt_project_evaluator_test.int_all_graph_resources .. [RUN]
15:29:33  10 of 33 OK created table model dbt_project_evaluator_test.int_all_graph_resources  [CREATE TABLE (380.0 rows, 76.6 KB processed) in 4.16s]
15:29:33  11 of 33 START view model dbt_project_evaluator_test.fct_documentation_coverage  [RUN]
15:29:33  12 of 33 START view model dbt_project_evaluator_test.fct_model_naming_conventions  [RUN]
15:29:33  13 of 33 START view model dbt_project_evaluator_test.fct_source_directories .... [RUN]
15:29:33  14 of 33 START view model dbt_project_evaluator_test.fct_undocumented_models ... [RUN]
15:29:33  12 of 33 ERROR creating view model dbt_project_evaluator_test.fct_model_naming_conventions  [ERROR in 0.48s]
15:29:33  15 of 33 START table model dbt_project_evaluator_test.int_direct_relationships . [RUN]
15:29:33  14 of 33 ERROR creating view model dbt_project_evaluator_test.fct_undocumented_models  [ERROR in 0.59s]
15:29:33  13 of 33 ERROR creating view model dbt_project_evaluator_test.fct_source_directories  [ERROR in 0.80s]
15:29:34  11 of 33 OK created view model dbt_project_evaluator_test.fct_documentation_coverage  [OK in 1.15s]
15:29:36  15 of 33 OK created table model dbt_project_evaluator_test.int_direct_relationships  [CREATE TABLE (453.0 rows, 117.6 KB processed) in 3.09s]
15:29:36  16 of 33 START view model dbt_project_evaluator_test.fct_test_directories ...... [RUN]
15:29:36  17 of 33 START table model dbt_project_evaluator_test.int_all_dag_relationships  [RUN]
15:29:36  18 of 33 START view model dbt_project_evaluator_test.int_model_test_summary .... [RUN]
15:29:37  16 of 33 ERROR creating view model dbt_project_evaluator_test.fct_test_directories  [ERROR in 0.34s]
15:29:37  18 of 33 OK created view model dbt_project_evaluator_test.int_model_test_summary  [OK in 0.88s]
15:29:37  20 of 33 START view model dbt_project_evaluator_test.fct_test_coverage ......... [RUN]
15:29:37  19 of 33 START view model dbt_project_evaluator_test.fct_missing_primary_key_tests  [RUN]
15:29:37  19 of 33 ERROR creating view model dbt_project_evaluator_test.fct_missing_primary_key_tests  [ERROR in 0.33s]
15:29:38  20 of 33 OK created view model dbt_project_evaluator_test.fct_test_coverage .... [OK in 1.03s]
15:29:40  17 of 33 OK created table model dbt_project_evaluator_test.int_all_dag_relationships  [CREATE TABLE (1.9k rows, 134.1 KB processed) in 3.61s]
15:29:40  21 of 33 START view model dbt_project_evaluator_test.fct_chained_views_dependencies  [RUN]
15:29:40  22 of 33 START table model dbt_project_evaluator_test.fct_direct_join_to_source  [RUN]
15:29:40  24 of 33 START table model dbt_project_evaluator_test.fct_marts_or_intermediate_dependent_on_source  [RUN]
15:29:40  23 of 33 START view model dbt_project_evaluator_test.fct_exposure_parents_materializations  [RUN]
15:29:40  23 of 33 ERROR creating view model dbt_project_evaluator_test.fct_exposure_parents_materializations  [ERROR in 0.26s]
15:29:40  25 of 33 START view model dbt_project_evaluator_test.fct_model_directories ..... [RUN]
15:29:40  22 of 33 ERROR creating table model dbt_project_evaluator_test.fct_direct_join_to_source  [ERROR in 0.29s]
15:29:40  26 of 33 START table model dbt_project_evaluator_test.fct_model_fanout ......... [RUN]
15:29:40  24 of 33 ERROR creating table model dbt_project_evaluator_test.fct_marts_or_intermediate_dependent_on_source  [ERROR in 0.33s]
15:29:40  27 of 33 START table model dbt_project_evaluator_test.fct_multiple_sources_joined  [RUN]
15:29:40  21 of 33 ERROR creating view model dbt_project_evaluator_test.fct_chained_views_dependencies  [ERROR in 0.41s]
15:29:40  28 of 33 START table model dbt_project_evaluator_test.fct_rejoining_of_upstream_concepts  [RUN]
15:29:40  25 of 33 ERROR creating view model dbt_project_evaluator_test.fct_model_directories  [ERROR in 0.28s]
15:29:40  29 of 33 START table model dbt_project_evaluator_test.fct_root_models .......... [RUN]
15:29:40  26 of 33 ERROR creating table model dbt_project_evaluator_test.fct_model_fanout  [ERROR in 0.28s]
15:29:40  30 of 33 START table model dbt_project_evaluator_test.fct_source_fanout ........ [RUN]
15:29:41  27 of 33 ERROR creating table model dbt_project_evaluator_test.fct_multiple_sources_joined  [ERROR in 0.34s]
15:29:41  31 of 33 START table model dbt_project_evaluator_test.fct_staging_dependent_on_marts_or_intermediate  [RUN]
15:29:41  28 of 33 ERROR creating table model dbt_project_evaluator_test.fct_rejoining_of_upstream_concepts  [ERROR in 0.33s]
15:29:41  29 of 33 ERROR creating table model dbt_project_evaluator_test.fct_root_models . [ERROR in 0.32s]
15:29:41  32 of 33 START table model dbt_project_evaluator_test.fct_staging_dependent_on_staging  [RUN]
15:29:41  33 of 33 START table model dbt_project_evaluator_test.fct_unused_sources ....... [RUN]
15:29:41  30 of 33 ERROR creating table model dbt_project_evaluator_test.fct_source_fanout  [ERROR in 0.36s]
15:29:41  31 of 33 ERROR creating table model dbt_project_evaluator_test.fct_staging_dependent_on_marts_or_intermediate  [ERROR in 0.29s]
15:29:41  32 of 33 ERROR creating table model dbt_project_evaluator_test.fct_staging_dependent_on_staging  [ERROR in 0.28s]
15:29:41  33 of 33 ERROR creating table model dbt_project_evaluator_test.fct_unused_sources  [ERROR in 0.28s]
15:29:41
15:29:41  Finished running 18 view models, 15 table models in 0 hours 0 minutes and 20.66 seconds (20.66s).
15:29:41
15:29:41  Completed with 18 errors and 0 warnings:
15:29:41
15:29:41  Runtime Error in model fct_model_naming_conventions (models/marts/structure/fct_model_naming_conventions.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: c1e747b1-48d9-4498-8c03-fe1fc1e18d75)
15:29:41
15:29:41  Runtime Error in model fct_undocumented_models (models/marts/documentation/fct_undocumented_models.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 812fd23a-00f1-47d4-9ae4-a56e4d9f930b)
15:29:41
15:29:41  Runtime Error in model fct_source_directories (models/marts/structure/fct_source_directories.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: f8db37e8-9a69-4cf3-8e85-e13b5d8ce4a5)
15:29:41
15:29:41  Runtime Error in model fct_test_directories (models/marts/structure/fct_test_directories.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 9e8c8462-9402-4196-8cf6-ad62431e1c31)
15:29:41
15:29:41  Runtime Error in model fct_missing_primary_key_tests (models/marts/tests/fct_missing_primary_key_tests.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 0087d812-3cd6-465a-8b0b-d71d8baeae54)
15:29:41
15:29:41  Runtime Error in model fct_exposure_parents_materializations (models/marts/performance/fct_exposure_parents_materializations.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 4b9bcc9d-c3a0-461b-9b94-8b94f66ecddb)
15:29:41
15:29:41  Runtime Error in model fct_direct_join_to_source (models/marts/dag/fct_direct_join_to_source.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: b6d18cd2-5e1b-4e36-bbc2-d35c1938b53f)
15:29:41
15:29:41  Runtime Error in model fct_marts_or_intermediate_dependent_on_source (models/marts/dag/fct_marts_or_intermediate_dependent_on_source.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 189a1e98-a51f-4781-8330-a1bb7433cce1)
15:29:41
15:29:41  Runtime Error in model fct_chained_views_dependencies (models/marts/performance/fct_chained_views_dependencies.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 0d10cf36-8ed7-4ad1-9a8b-adf29012feb5)
15:29:41
15:29:41  Runtime Error in model fct_model_directories (models/marts/structure/fct_model_directories.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 60c7da87-ffe1-410d-bd66-a8b00fe57930)
15:29:41
15:29:41  Runtime Error in model fct_model_fanout (models/marts/dag/fct_model_fanout.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 2024f312-a445-4329-9b54-80f3ec500aec)
15:29:41
15:29:41  Runtime Error in model fct_multiple_sources_joined (models/marts/dag/fct_multiple_sources_joined.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: c63b1067-ead5-42c3-a4ed-8888755239f7)
15:29:41
15:29:41  Runtime Error in model fct_rejoining_of_upstream_concepts (models/marts/dag/fct_rejoining_of_upstream_concepts.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 20710606-0ca7-4ae1-993d-2afa1cc3969a)
15:29:41
15:29:41  Runtime Error in model fct_root_models (models/marts/dag/fct_root_models.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 270032c2-c145-4718-8a51-a20e04acca04)
15:29:41
15:29:41  Runtime Error in model fct_source_fanout (models/marts/dag/fct_source_fanout.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: 9880700c-6969-420a-9b17-af0a06d8eecd)
15:29:41
15:29:41  Runtime Error in model fct_staging_dependent_on_marts_or_intermediate (models/marts/dag/fct_staging_dependent_on_marts_or_intermediate.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: f44016c5-46f4-4745-b8c2-4cf6a3f9f91c)
15:29:41
15:29:41  Runtime Error in model fct_staging_dependent_on_staging (models/marts/dag/fct_staging_dependent_on_staging.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: e13e914f-e1ef-43f8-9a26-0c9cbad3e897)
15:29:41
15:29:41  Runtime Error in model fct_unused_sources (models/marts/dag/fct_unused_sources.sql)
15:29:41    404 Not found: Table inq-warehouse:dbt_project_evaluator_test.dbt_project_evaluator_exceptions was not found in location US
15:29:41
15:29:41    (job ID: dfb1ebb7-d802-48c5-b335-c5e47258fdca)
15:29:41
15:29:41  Done. PASS=15 WARN=0 ERROR=18 SKIP=0 TOTAL=33

System information
packages:
  - package: dbt-labs/dbt_utils
    version: [">=0.8.6", "<0.10.0"]
  - package: calogica/dbt_expectations
    version: [">=0.5.8", "<0.6.0"]
  - package: dbt-labs/metrics
    version: [">=0.3.1","<0.4.0"]
  - package: dbt-labs/codegen
    version: 0.8.0
  - package: data-mie/dbt_profiler
    version: 0.4.1
  - package: dbt-labs/dbt_project_evaluator
    version: [">=0.2.0","<0.3.0"]

Which database are you using dbt with?

[ ] postgres
[ ] redshift
[x] bigquery
[ ] snowflake
[ ] other (specify: ____________)

The output of dbt --version:
dbt Core: 1.2.2
bigquery adapter: 1.2.0

Additional context
Notably, our production target is running all of the dbt_project_evaluator models successfully, though our production target has run several 0.1.x versions of dbt_project_evaluator previously, so I guess at some point the dbt_project_evaluator_exceptions model stopped being deployed.

Nevermind, I had to run dbt seed first 😅. Closing.

Hi! Yes, the README mentions using dbt build --select package:dbt_project_evaluator for that same reason 😄
Glad that you got around it yourself.


added Fred Martin

Dear Amy - would you add me to your wonderful resource list of CER people? Thank you, Fred.

Yes, happily!


Linter doesn't care about comment style

Linter allow you to do any of these:
//PublicStruct ...

type PublicStruct struct {}

// PublicStruct ...

type PublicStruct struct {}

Thanks for the issue.
This appears to be out of scope and so is being closed. If you feel this is in error please feel free to re-open.
Please note this is not the forum to discuss edits to CodeReviewComments. If you wish to propose changes to it please send a mail to golang-nuts.


Dynamical mapping of platform from problemlist to PLATFORM added

Solves #2910 please review @llxia @smlambert

@llxia - I will defer to your feedback on this PR.

Thanks @prahasR for working on this. Sorry, this fell off my radar.
The expected solution is to remove platform_map completely, so we do not need to update the map for future platforms.
For example, linux-aarch64 can be matched to aarch64_linux by switching the order and changing the - to _.
@prahasR could you update this PR? Thanks

I will close this PR as it is obsolete. Please feel free to open a new PR with the update. Thanks.


electron-packager does not recognize 64-bit wine installations that do not include the wine64 command

Preflight Checklist

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Issue Details

Electron Packager Version:

17.1.1

Electron Version:

24.3.1

Operating System:

Debian 12 (bookworm) amd64

Expected Behavior
With 64-bit WINE installed via apt, it should build without any issues.
Actual Behavior
electron-packager checks for wine64, and fails to find it as debian does not package the wine64 command.
To Reproduce
Create an electron-packager app on Debian 12 (bookworm), install wine, and build for the win32 target.
Additional Information
An easy workaround for this issue is to simply create a wrapper script in the $PATH with the name wine64 that simply runs the regular wine command and passes the arguments provided to the script.

I've had a similar issue with wine not working in our kubernetes/jenkins environment, but wine64 working fine.
I had no control on what electron-builder uses though, so I symlinked wine to wine64 via ln -sf /usr/bin/wine64 /usr/bin/wine

Upstream issue: https://github.com/electron/windows-installer/issues/513


User consent policy

Our organization maintains robust user privacy policies. Prior to implementing this tool, we seek clarity on your stance regarding user privacy and compliance with the General Data Protection Regulation (GDPR). Could you kindly provide information about your approach to privacy and whether there is a privacy policy for this library that we can review? Are there any steps we should take prior to implementation of this tool regarding user consent?

This library is simply a wrapper around some standard Web APIs which implements best practices in using those APIs to gather performance data for sites to do with as they please (report back to an analytics solution, or just log for debugging). The library does not send this data anywhere by default.
Therefore, we do not provide any guidance on any privacy implications or consent necessary when gathering and reporting back the data this library facilitates.


Update package Libsolv to version 0.7.27

Changes to be committed:
modified:   ../SPECS/libsolv/libsolv.signatures.json
modified:   ../SPECS/libsolv/libsolv.spec
modified:   ../cgmanifest.json
modified:   resources/manifests/package/pkggen_core_aarch64.txt
modified:   resources/manifests/package/pkggen_core_x86_64.txt
modified:   resources/manifests/package/toolchain_aarch64.txt
modified:   resources/manifests/package/toolchain_x86_64.txt

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[ ] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary

Update package Libsolv to version 0.7.27
Change Log

Changes to be committed:
modified:   ../SPECS/libsolv/libsolv.signatures.json
modified:   ../SPECS/libsolv/libsolv.spec
modified:   ../cgmanifest.json
modified:   resources/manifests/package/pkggen_core_aarch64.txt
modified:   resources/manifests/package/pkggen_core_x86_64.txt
modified:   resources/manifests/package/toolchain_aarch64.txt
modified:   resources/manifests/package/toolchain_x86_64.txt
Does this affect the toolchain?

YES
Test Methodology

Local build
Pipeline build id: xxxx

newer revision than the one I have right now I have 0.7.27 and seems that 0.7.28 is out I think I'll abandon this review and start a new one with the latest revision


signing a single message

To integrate the Fiat exchange service into the Light Wallet we need the functionality to sign a simple message. When trying to sign a message with the newest version (v0.7.0) of the wallet with const signature = await account.sign(hash), an exception with the message No UI attached for passphrase prompting is thrown. This worked in older versions (<= v0.5.3). I followed the hint in WalletNodeProvider to TransactionAuthorization, but couldn't figure out how to sign a single message (not a transaction).
Is anyone willing to give a hint on how to do the signing with the newest version?

When trying to sign a message with the newest version (v0.7.0) of the wallet with const signature = await account.sign(hash), an exception with the message No UI attached for passphrase prompting is thrown.

Hi @davidleomay I am guessing this happened in your code thus the error message No UI attached for passphrase prompting
const accountFromWalletContext = useWallet()
const signer = (accountFromTransactionAuth) => {
  // accountFromWalletContext.sign() // this will fail
  accountFromTransactionAuth.sign()
}

To integrate the Fiat exchange service into the Light Wallet we need the functionality to sign a simple message.

This is actually a different use case, signing any message for other integration). As you can see our code setup a flow to perform a signing which output CTransactionSegwit. So you have to setup another "action" which will proceed with your desired implementation after the passphrase collected from user.
const provider = MnemonicEncrypted.initProvider(providerData, network, { prompt: onPrompt })
const wallet = initJellyfishWallet(provider, network, client)
wallet.get(0).sign(<your custom message here>)

Hi @ivan-zynesis, thanks for your explanation, that helped very much. The TransactionAuthorization contains all the logic to enter the pin code, but it is specific for signing transactions. If we now want to sign a message, we would need to copy/re-implement most of the UI and logic to enter and validate the pin code. Is that correct?
Are there any plans on your side to extract this common logic? Or is there a simpler way to reuse it?

Yes, it is possible to reuse the entire pin input UI + logic implementation (thus it handle pin attempt counter, retry logic etc). Assuming your codebase still have very similar structure as this repo. Following snippet should fit your use case.
   const auth: Authentication<Buffer> = {
      consume: async passphrase => {
        // quickly instantiate a wallet to sign your message
        const provider = MnemonicEncrypted.initProvider(providerData, network, { prompt: () => passphrase }) // feed collected value directly
        const wallet = initJellyfishWallet(provider, network, client)

        // it will throw error here and direct to next attempt if passphrase invalid
        return await wallet.get(0).sign(<your custom message here>)
      },
      onAuthenticated: async (signature: Buffer) => {
        // TADA!
        continueWithYourIntegration(signature)
      },
      onError: e => Logging.error(e),
      message: 'todo',
      loading: 'todo'
    }
    dispatch(authentication.actions.prompt(auth))

https://github.com/DeFiCh/wallet/blob/main/app/screens/AppNavigator/screens/Settings/SettingsScreen.tsx#L36-L45


Mihomo mixed-port config support

Is your feature request related to a problem? Please describe.
Thanks for your fabulous work. The CLI itself is smooth, lightweight and extremely convenient and I love it. Mihomo support setting mixed-port which can be used for both http and socks port. Mohoro seems not supporting it now.
Describe the solution you'd like
Add an additional config item into config.rs to parse the mixed-port config to mihomo. I can also help to create the PR to contribute if the maintainers have no free time to add this feature.
Describe alternatives you've considered
None.
Additional context
None.

You are more than welcome to create the PR ;)


Update audio-hijack to 3.3.5

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if updating a cask:

[ ] sha256 changed but version stayed the same (what is this?).
I’m providing public confirmation below.

Thank you for the contribution. It was merged directly as f78ad2eeb51d5e4894a99eb631d26397bcacc50f. Your contribution is still credited to you.


Profile fields styling fixes

add responsive css to fix issue of fields in profile being cut off in smaller browser sizes (e.g. name, birthday fields and footer)

add async attribute to ajax calls in timezone section, deceased status section, a slight performance boost

this is not quite ready yet.  I saw some styling issues in safari and firefox, fixing them now.  Will inform when this is ready.

This PR is ready for reviewing.  Thanks.