To workaround the InvalidMutabilityException
As mentioned in this https://discuss.kotlinlang.org/t/kotlin-native-1-3-50-relaxed-mode/13586
You can do it with the compiler flag -memory-model relaxed. Please avoid using this feature in production, as the model is still in the experimental stage of development.
Related
SQLDelight is still marked as experimental library on maven repository here, though the first version seems to be released in October 2018.
I made a sample app in KMM where I'm able to insert/delete rows, and it seems to be working fine for our use case so far. But, can someone help me understand what aspects of it would not be safe for usage in prod. Are there any perf issues? Or is there any possibility of random crashes in prod? Or, do we know if there are apps which successfully use SqlDelight in Prod for their KMM applications?
Thanks!
I don't know why that link describes sqldelight as experimental for multiplatform. Many apps currently ship with sqldelight on iOS.
I wrote the underlying driver (https://github.com/touchlab/SQLiter/) and work with team and community to maintain the sqldelight implementation.
There's nothing that I don't think is production ready. Performance had some sore spots, but there's been considerable attention paid to that recently. I haven't run many benchmarks but I would expect sqldelight to compare favorably to anything out there doing similar work.
I have a target which can only be built for Linux (in this case, because it depends on syscalls only available on Linux and there is no desire to try and make this cross-platform). How can I express this in my BUILD files?
I can see from the Platforms documentation that there exists a Linux platform definition as #bazel_tools//platforms:linux, but it is not clear to me how to make use of this to restrict a target. Trying to specify this in compatible_with results in an error like this:
(13:27:09) ERROR: /foo/BUILD:4:1: in compatible_with attribute of go_library rule //foo:go_default_library: constraint_value rule '#bazel_tools//platforms:linux' is misplaced here (expected environment). Since this rule was created by the macro 'go_library_macro', the error might have been caused by the macro implementation in /foo/BUILD:4:1
So I have a few related questions:
The error seems to indicate I've supplied the wrong type of rule to compatible_with. What is an environment and how do I provide one? (I've struggled to find documentation on this)
I gather that the migration to Platforms might not yet be complete and rules_go might not have been updated. If it's not possible with Platforms, is there an "old way" to do this instead?
Ideally, I would like this not to result in build errors when running commands like bazel test //:all on a different (non-Linux) platform – ie. I'd prefer it just exclude these, or something. Is this possible?
Thanks for your help 😊
Turns out that this is an open issue. Once this is fixed, I think it should be possible: https://github.com/bazelbuild/bazel/issues/3780
First of all, I'm sorry to ask a somewhat vague question but I'm only doing it because I'm clueless to what might be causing the problem.
I've been building an app with Sprite Kit and it has worked great. I've made some additions to code at suddently I see a dramatic decrease in performance. I have rolled back all my code changes but the performance didn't go up. I'm left clueless to what's wrong.
After hidious debugging I've noticed that the performance problem only affects run and test builds. If I do a profiling build, the app behaves as normally = with high performance. So this would suggest that my problem is somewhere in the build configuration but I'm completely new to ios build environment configurations.
Can anybody suggest what might be the cause of this? Where should I start looking? I have my background in Java 5 and the compiler and other settings are quite strange to me.
The default setup is to have a Debug config and a Release config, where Debug is configured with no optimizations, and Release does include optimizations. Optimizing often makes it hard to use the debugger, which is why unoptimized code is preferred there.
By default, Run, Test, and Analyze use the Debug config, Profile and Archive use the Release config. Your change in behavior could come from lots of differences: you may have had it configured before to build for Run in Release mode. You may have had a subproject built in Release mode that is now in Debug. You may have made a coding change that is very slow unless the optimizer is used. (Since you say you rolled back the code, this last one is unlikely, but check your version control and see if you changed any project settings.)
If you're seeing weird "it wasn't like that before" behavior when you think you've put everything back, make sure you're rebuilding everything. Delete your Derived Data directory. You can determine where it is in Preferences, Locations. "Delete your Derived Data directory" is the Xcode-equivalent of "try rebooting." It's the most common way to fix strange "Xcode isn't working right" problems. In fact, I put my Derived Data in /tmp/build so that it gets deleted every time I reboot (and so the path is easier for me to remember).
We recently built the 3.3 release of clang/llvm using the Fedora 20 packaging process as a guide to unpacking, moving the different parts to the correct location and building the compiler tool chain. All seems to be working correctly except the dynamic memory analyzer is not referencing back to the source code. The same usage on the Fedora platform does reference back to the source code.
This is our first attempt to use the clang/llvm tool set. Also this is the first question asked in this forum which seems a bit different on its organization from all the others I have participated in so my appologies in advance if I have not figured out the nuances of posting a question here. Does seem odd that the main projects do not seem to have a way of asking questions.
We found a solution, do not know quite why we needed to add the extra
environment setup. Compiling as follows:
PATH=/net/fas4045/home3/jq031c/llvm_sandbox/bin:$PATH make -j 16
DEPFILES= CXX=clang++ CC=clang CXXFLAGS="-fsanitize=memory
-fsanitize-memory-track-origins -fno-omit-frame-pointer"
LDXFLAGS=-fsanitize=memory
Runing as follows:
MSAN_SYMBOLIZER_PATH=/net/fas4045/home3/jq031c/llvm_sandbox/bin/llvm-symbolizer ./runtests.sh
We can understand that we need to add the analysis option to the link flags as we do a two step build of compile followed by link. The discovery after searching was the need to define the path to llvm-symbolizer with an environment variable which none of the other dynamic analysis options seems to need.
I'm using TJvPluginManager in the JVCL to create and load BPL-based plugins for my program. Problem is, one of the plugins isn't loading properly, and I can't debug it. Every time I try to trace into the loading sequence, it gets as far as the LoadLibrary API call, and then the debugger seems to forget what it's there for. It completely loses the ability to associate program code with source lines, give meaningful data in a call stack, or display local variables. It will still stop at breakpoints, but it breaks to the CPU window, with all the inline source code stripped out.
This happens on Delphi 2007 and 2009, and it's driving me nuts. Does anyone know how to load a plugin without it breaking the debugger? Does anyone even know why it's breaking it in the first place?
NOTE: I'm not looking for alternative methods of debugging. I know all about tracing and logging and all the rest. What I want is to understand what's going wrong and how to fix it. Surely I'm not the only person who's ever used TJvPluginManager?
Not quite the answer to your question: Have you tried to debug the package project, by setting the host application and putting a breakpoint into the package's startup code?
I've found Ray Kanopka's (Raize) CodeSite to be invaluable for debugging in situations where the integrated debugger is acting up. Thinking about the things I want to monitor using CodeSite actually helps me focus on what's important - it enforces good habits.
Another alternative to Codesite is Overseer which is part of the nexus project, but stands alone so does not require you to use their framework. Codesite is by far the better option, but in a pinch Overseer would work just as well.
I found that using packages for plugins can be problematic and many years ago switched to a completely COM based implementation for plugins and never had any problems. The other advantage to COM based plugins, they don't require Delphi to write, do not need to be recompiled when the main app switches to a new version of the compiler (my plugins compiled with Delphi 5 still run fine against the main application compiled in Delphi 2009!) and they are easier to write test applications to assist in debugging.
The only side effect I notice, is that shared code ends up in both executables and the plugins require registration into the registry.
Hmmmm... This is a stupid question, but I have to ask: the initialization function have the EXACT declaration syntax like the other plugins that work ?(from your question, I deducted you made some others that work)
Check your dependencies. Make sure each unit is compiled into one package only. Whenever a package needs to reference a unit from another package, use the requires clause to do so. Watch for compiler warnings about implicitly linked units.