microk8s disable ha-cluster clears data

When disabling ha-cluster the database is cleared. I expected something along these lines to happen moving between etcd and dqlite but just in case it's not expected behaviour I thought I would add it here.

Hello,
I'm facing the same issue for a small home test lab. I have a 3 node cluster (single Hyper-V host with 3 Microk8s VM nodes). I want to replace the Hyper-V host with a single bare metal Intell NUC.
I was hoping to add the NUC in the cluster, disabling HA and then removing the other nodes. But after disabling HA on the NUC it is no longer a cluster member. Instead it is a single node cluster on its own.
Is there another way to migrate from a 4 node HA cluster to single node cluster?

@richardbeumer you do not need to disable HA. You can add your new node to the cluster and then remove one-by-one the other nodes. The new NUC node should take over the Kubernetes datastore. @freeekanayaka correct me if I am wrong.

@ktsakalozos that's correct, although I'm not sure this particular scenario was tested. It should work.

@ktsakalozos  gave it a try. But when I remove the last node my cluster becomes complete unresponsive. I have to restore the last node for the cluster to become responsive again.

I tried it too.  There is a check on leave command preventing the user to remove a node when it is the only leader remaining.

I just ran into the same "problem". I was investigating CPU issues and thought: I run microk8s on a single node, I can disable the ha-cluster plugin, maybe it is using all the CPU, it can't hurt – well, wrong. It DOES hurt.
I think this is very critical. There is no warning whatsoever :confused: All deployments, services, all pods, and all persistent volumes are gone after disabling the plugin. Re-enabling the plugin does not bring back anything, the node remains empty :(
There should be a big fat warning or at least having the user confirm that they are about to delete all their data.

Exact same issue for me. MicroK8s has 100% usage on a poor Intel Atom CPU, read that disabling ha-cluster helps, disabled ha-cluster, all data gone. No backups since this is a homelab machine 🗡 (didn't hurt that much other than I don't have time to rebuilt it now)

Hello,
I'm facing the same issue. Is it possible to add, at least, a warning about it when disabling ha-cluster?
Or require an argument like "--force" ?
Thanks
Regards

Hello,
When I try to remove the HA from the third and last node, I received an error message about that it is the node with the last copy of k8s data and it prevent me from disabling ha.
So I revert all by re-enabling the HA cluster on the first and second nodes and readding them to the third node.
In the end the config is never lost, is kept on the last node.
Also in the cluster I use rook-ceph and no volume data has been lost.
Regards

We have PR [1] ready that adds a --force requirement to the disable ha-cluster when you have a single node.
That should be released with v1.21.
[1] https://github.com/ubuntu/microk8s/pull/2143

Hello, is there any way to set up default services/pods/... after disabling HA? After it is hardly usable.
So far I have dumped the whole default deployment but it requires some cleaning which I want to avoid.

Is the default config available somewhere to apply? Or as I did, I need to dump it?

I am sorry, what is the default config?

The One after fresh installation, but without HA

There is no config to apply after the ha is disabled. The cluster should be completely empty. You should only see the kubernetes service, nothing else.

In my opinion, there should be some guidance at least how to configure cluster without HA, despite it known performance issues. I exported the node configuration before disabling HA, with kubectl get all --all-namespaces -o yaml > ..., disabled HA, applied the file (after 5 mins of cleanup) and... service accounts not found, because this resource is not available in all macro. On the new node, I exported them and applied again base configuration with these... so far so good.
Now lets add new node with add-node. On the worker node (fresh installation) I paste the command from master (microk8s join ... and guess what?

Connection failed. Not possible to join. This is not an HA MicroK8s cluster (501).

Why is it so hard to set up without HA? is it a feature that also requires at least 3 nodes, which I suppose some clients do not have, or rather a must-have?

Data is also removed if you have an old node and install "ha-cluster"
No warnings, nothing. All config is removed.  Very frustrating!


[zlib] build failure

Operating system
x64-windows
Compiler
MSVC 19.35.32217.1
Steps to reproduce the behavior
vcpkg install cpr:x64-windows-static

Failure logs
-- Using cached madler-zlib-v1.2.13.tar.gz.
-- Cleaning sources at C:/vcpkg/buildtrees/zlib/src/v1.2.13-f30d2a168d.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/vcpkg/downloads/madler-zlib-v1.2.13.tar.gz
-- Applying patch 0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch
-- Applying patch 0002-skip-building-examples.patch
-- Applying patch 0003-build-static-or-shared-not-both.patch
-- Applying patch 0004-android-and-mingw-fixes.patch
-- Using source at C:/vcpkg/buildtrees/zlib/src/v1.2.13-f30d2a168d.clean
CMake Error at ports/zlib/portfile.cmake:18 (vcpkg_cmake_configure):
Unknown CMake command "vcpkg_cmake_configure".
Call Stack (most recent call first):
scripts/ports.cmake:147 (include)
Additional context
No response

Did you uninstall this before?  You could try deleting the build tree (C:/vcpkg/buildtrees/zlib) and the archive.

same as https://github.com/microsoft/vcpkg/issues/30965

git clean -xffd and pull again helps
Ty


Capsule Network example training

First I want to take the chance to thank you for your videos, tutorials, books and for publishing the notebooks in a public repo! Thank you!
I recently started looking at Capsule Networks and found your tutorials extremely useful! However, when I tried to run the notebook everything runs normally, no errors or anything, the loss seems to be low, but the accuracy is just around 9% and when I try to run the reconstruction example I get just random blobs, so I was wondering if it is a common problem or is it just me? I tried deleting everything and cloning the repo again and getting a new Anaconda environment and got the same results. Do you know what the reason for this may be and how can I resolve it? Probably there is something up with the loss calculation, but to be fair thre shouldn't be.. I'm attaching screenshots of the reconstructions and the caps output vectors.

Any help will be appreciated!

I'm seeing this issue on my desktop box running Ubuntu 18.04 with python and tensorflow installed using anaconda.
Running with GPU on Colab it runs fine.
Looking at data flowing through the first 5 items of the first batch give identical results on both environments and after that the differ. If I run a batch_size of 5 on my desktop then it runs fine, batch_size 6 and it is wrong. Trying to find out why, but not there yet.

Problem is due to calling tensorflow.matmul with more than 2**16 matrix multiplies. It is a bug in CUDA 10.0 but fixed in 10.1. See https://github.com/tensorflow/tensorflow/issues/32877


flip looses the arity of the function

Thus automatic currying a flipped function is not possible. Instead one needs to specify the arity using curry_n.
I guess that behavior should be mentioned in the documentation.
I wonder if argument flipping is useful at all for n ≠ 2, because optional parameters on third and higher places will suddenly become compulsory.
Especially when providing a curried, data-last version of functional-php for #118, I guess curry_n(2, flip('Functional\xxx')) covers nearly all cases.

Good point. I am not sure this is fixable in a way that will still perform well (e.g. without reflection). Give me a bit of time to think about it but at least mentioning it in the docs is something we should do.


Fixed uploading best model checkpoint in NeptuneLogger

What does this PR do?

Fixes #10602
Adds best model checkpoint uploading to NeptuneLogger.
Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[x] Did you list all the breaking changes introduced by this pull request?
[x] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

Seems our codeowners github trigger did not work. They were not requested for review.
https://github.com/PyTorchLightning/pytorch-lightning/blob/edbf27430d02b59da717a870d98154f3dbea8ff1/.github/CODEOWNERS#L29
Pinging them manually for now:
@shnela @HubertJaworski @pkasprzyk @pitercl @Raalsky @aniezurawski @kamil-kaczmarek
Could one of you have a quick look? Thx

@awaelchli
approved.

The hanging tests were fixed on master. I tried to update the branch but don't have write access. Could you please do it so we can merge the fix?

@awaelchli Is there anything should I take care of?

Nope, thanks for the reminder. Will check back once tests have run

Thanks @kamil-kaczmarek , this fix will be included next week in the bugfix release 1.5.5.

Great thanks, kudos to @Raalsky for leading this bug fix :tada:


[chore] runs native classes codemod for apps/helpers

A continuation of #2227 that runs the native classes codemod against app/helpers.
This one was really easy, all the of the helpers are already converted!
Please include a description of your change & check your PR against this list, thanks!

[x] There's a clear use-case for this code change
[x] Commit message has a short title & references relevant issues
[x] The build will pass (run ember test from the repo root - will be core/client if working from the submodule in Ghost).

More info can be found by clicking the "guidelines for contributing" link above.

Codecov Report

Merging #2241 (2dfb685) into main (eeaf546) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2241   +/-   ##
=======================================
  Coverage   37.50%   37.50%
=======================================
  Files         552      552
  Lines       21998    22000    +2
  Branches     3939     3939
=======================================
+ Hits         8250     8251    +1
- Misses      13748    13749    +1

Impacted Files
Coverage Δ

app/helpers/gravatar.js
100.00% <ø> (ø)

app/helpers/members-event-filter.js
84.21% <100.00%> (+1.85%)
:arrow_up:

app/components/gh-html-iframe.js
45.45% <0.00%> (-38.64%)
:arrow_down:

app/controllers/offer.js
45.24% <0.00%> (+0.90%)
:arrow_up:

app/components/gh-image-uploader.js
95.33% <0.00%> (+1.33%)
:arrow_up:

app/components/gh-file-uploader.js
94.61% <0.00%> (+3.07%)
:arrow_up:

app/components/gh-site-iframe.js
68.00% <0.00%> (+16.00%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eeaf546...2dfb685. Read the comment docs.

https://github.com/TryGhost/Ghost/issues/14101


Peeking into an iterator

Hypothetical code, but not very far from my use case:
from chardet.universaldetector import UniversalDetector

with peekerator(bytestream) as (peek, bytestream):
    detector = UniversalDetector()

    async for chunk in peek:
        detector.feed(chunk)
        if detector.done:
            break

    encoding = detector.close().get('encoding')
    async for line in iterdecode(bytestream, encoding):
        print(line)

With bytestream being something like starlette.requests.Request.stream(). And here's my implementation of peekerator, which I think would be a nice addition to aioitertools.
from collections import deque
from contextlib import contextmanager
from aioitertools.builtins import iter

@contextmanager
def peekerator(iterator):
    it = iter(iterator)
    cache = deque()

    async def peek():
        async for el in it:
            cache.append(el)
            yield el

    async def real():
        while True:
            if cache:
                yield cache.popleft()
            else:
                try:
                    yield await it.__anext__()
                except StopAsyncIteration:
                    return

    yield peek(),real()

The idea is based on more_itertools.peekable but with an peeking iterator instead of method and without the added overhead of implementing prepend and indexing.
If there's interest in adding this, I'd package it up with tests and documentation as a pull request. The name is, of course, up for discussion.

No reaction for one and half years says it all.


⚠ Bofrost.at has degraded performance

In 3a59e41, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1234 ms

Resolved: Bofrost.at performance has improved in 4cf486d after 6 minutes.


Use ExactSizeIterator bound in command encoding methods

As a follow-up to https://github.com/gfx-rs/gfx/pull/3307 we'd want to put ExactSizeIterator bound on the methods that are called often, methods of trait CommandBuffer.
cc @khodzha

i found only wait_events and execute_commands are collecting into Vecs and not into SmallVecs
do you want only those to be bounded? :thinking:

SmallVec there is still risky, I'd ideally want to replace the uses of SmallVec with inplace_it or ArrayVec, maybe even removing smallvec completely from the dependencies. The concern about SmallVec is having a threshold. Once you cross it, there is a performance cliff. For example for the blit_image we have a capacity of 4. Once the user blits 5 regions, and it's perf-critical code, they hit a performance pitfall.
SmallVec is good when there is a "natural" cut-off. For example, if something has a "typically one, but sometimes many" semantics, it works. But if there is no "natural" cut-off point, then SmallVec is not a good fit.
If it's possible to enforce a compile-time maximum, ArrayVec is good. For example, we can define MAX_DESCRIPTOR_SETS: usize = 16 and cap the limits to it. So that we can use ArrayVec[_; MAX_DESCRIPTOR_SETS] for anything related.
In all other places (e.g. copy regions, or barriers), we don't have either the maximum, or a natural cut-off, so inplace_it works best.

Also, regardless of what Vulkan backend will use to back them, we need to add the ExactSizeIterator for the API, to allow future optimizations in all backends.


Add Support for Budgets endpoint

Docs here: https://developer.xero.com/documentation/api/budgets

Will post support also be added?

Just released Budgets support. This is still being rolled into the SDK's though.
@rocketman101 - I am asking about post support. Its not in there at the moment, but will update you @ this thread when I can get an answer.


HEAD: Update SSM features to match bsc1047702 fix

Port of #404 to master

https://github.com/SUSE/spacewalk-testsuite-base/blob/4ba13c0c690a1e1d55d6f92b319fe790622d9ea0/features/srv_create_group.feature#L48

That should not be needed @MalloZup - AFAIU that test does not fail (and it is not expected to fail).
Merging now.


Add source generator to VSIX

Adds source generator and its dependencies to VSIX.
Roslyn change: https://github.com/dotnet/roslyn/pull/63912

Need someone to hit the button, can't merge myself. Thanks!

Is VS Mac on your radar anywhere? On this side it should be easy enough to add the files to the mpack, but I've no idea how the other side works. The code is probably in the vsmac repo, not Roslyn, I would expect.

@davidwengier Good point. Roslyn's code that loads analyzers from VSIX certainly does not work from VS Mac. Not sure if there is an equivalent code in VS Mac.

Correct me if I'm wrong @chsienki, but I don't think VS Mac is blocking. Obviously the SDK is still going to get updates from this repo, so until there is some break in the compiler/tooling that means tooling no longer works with the SDK compiler, it's probably fine for VS Mac to lag a little. Plus I suspect such a break is undesirable for lots of other reasons. And besides that, the LSP editor is still behind a feature flag.

it's probably fine for VS Mac to lag a little.

I agree it's fine to lag a little but would like to know what the plan is there.

Yeah, in the immediate/short term this doesn't affect VSMac or VSCode, they'll keep loading it from the SDK. In the near future we're going to want to do the same thing for them as well though. I'm working on figuring out the overall architecture which should give us a good idea of how we want to achieve that. I'll open a couple of issues to track that specific work though so we don't forget about it:

[ ] VSMac should prefer MPack'ed generator over SDK
[ ] VSCode should prefer extension generator over SDK


Tests supporting multithreading

Hi,
I wanted to check if there is a plan to have tests running on multiple threads.. ?

We don't have particular plans to test running on multiple threads; our
current charter is to test that a hart is arhcitecturally compatible, and
(from an architectural point of view) there is no difference between
multi-theading and multiple processors. All those details are
micro-architectural, and ACTs are agnostic of micro-architecture.
At some point in the future we may add support for multi-harts,
primarily for memory model and atomic op testing - but this is a topic
under active discussion..
On Thu, Jun 1, 2023 at 5:26 AM animesh211 @.***> wrote:

Hi,
I wanted to check if there is a plan to have tests running on multiple
threads.. ?
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/358, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJUPGZ2FPXIP244M4GLXJCC7XANCNFSM6AAAAAAYW3AV2A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

The question was explained by @allenjbaum , so closing this one. You may reopen it anytime if you require any help


Remember me functionality

Hey
I trying to get remember me functionality. Can you hel please?
If user check "remember me" i need to create token with 365 day of lifetime or?
I need to store cookie and if cookie exists automaticly login and get token?
Tnx

@marijang Hi, So did you implemented 'Remember Me' using OAuth2. How is the workflow ? I am also trying to do same thing.

Same here. Where to store access token? Next time the user visits or refreshes the page, access token won't be send in HTTP header or url query parameters and the server code will redirect user to login page as there is no access token? How to solve this problem?


OpenAIStreamTextResponse breaks when agent tries to use a tool

While using Agent.run_stream to get a response of type StreamedRunResult and using the method StreamedRunResult .stream_text with delta=True to stream the response, I encounter an error when the agent attempts a tool call.
Here is the stacktrace (with some censoring of filepaths):
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "<...>/src/__main__.py", line 48, in <module>
    asyncio.run(streamed_response(user_input))
  File "/Users/work/.pyenv/versions/3.11.4/lib/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/Users/work/.pyenv/versions/3.11.4/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/work/.pyenv/versions/3.11.4/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "<...>/src/agents/system.py", line 113, in stream_response
    async for message in response.stream_text(delta=True):
  File "<...>/venv/lib/python3.11/site-packages/pydantic_ai/result.py", line 181, in stream_text
    async for _ in group_iter:
  File "<...>/venv/lib/python3.11/site-packages/pydantic_ai/_utils.py", line 204, in async_iter_groups
    item = done.pop().result()
           ^^^^^^^^^^^^^^^^^^^
  File "<...>/venv/lib/python3.11/site-packages/pydantic_ai/models/openai.py", line 323, in __anext__
    assert choice.delta.content is not None, f'Expected delta with content, invalid chunk: {chunk!r}'
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Expected delta with content, invalid chunk: ChatCompletionChunk(id='chatcmpl-AfoW4ddgsqIMtK9fRp4EsE2mh0W5d', choices=[Choice(delta=ChoiceDelta(content=None, function_call=None, refusal=None, role=None, tool_calls=[ChoiceDeltaToolCall(index=0, id='call_ZK4LQLjd9buO0Zq3NnFRA3WO', function=ChoiceDeltaToolCallFunction(arguments='', name='write_file'), type='function')]), finish_reason=None, index=0, logprobs=None, content_filter_results={})], created=1734528996, model='gpt-4o-2024-05-13', object='chat.completion.chunk', service_tier=None, system_fingerprint='fp_f3927aa00d', usage=None)

I believe the error is happening here and might arise due to the fact that as the agent calls the tool the choice.delta.content is None, however the ChatCompletionChunk has begun making a tool call to the function 'write_file' as you can see in the stacktrace.

cc @dmontagu.
This should be fixed by #468

any workarounds that can be done while the fix is merged ?


Issue with "Create an Integration" in @site/docs/tutorials/tut-integration-ui.md : Missing image for Short Text param API URL

Describe the problem

Page: Create an Integration
Source: https://github.com/demisto/content-docs/tree/master/docs/tutorials/tut-integration-ui.md

The API Encrypted param type is repeated twice in the image. First image should be API URL as short text according to description.

Screenshots

Environment

OS: Mac
Browser: Chrome
Browser Version: 87.0.4280.141

Suggested fix

@vibhuabharadwaj thanks for reporting this. Will be fixed soon.


[BUG] Can't import module with name memoryview in cython>=3

Describe the bug
Any package that named memoryview is interpreted as a builtin type. This will crash at runtime (see code) from cpython cimport memoryview as _memoryview, however this works from cpython.memoryview cimport PyMemoryView_FromMemory
Code to reproduce the behaviour:
cimport cpython
from cpython cimport memoryview as _memoryview
import numpy as _numpy

from libc.stdlib cimport malloc
from libc.stdint cimport intptr_t

cpdef test_mem(size_t size):
    cdef int* vec = <int*> malloc(size * sizeof(int))

    for i in range(size):
        vec[i] = i

    cdef object buf = _memoryview.PyMemoryView_FromMemory(
        <char*><intptr_t>vec, size * sizeof(int), cpython.PyBUF_READ)
    return _numpy.ndarray((size,), buffer=buf, dtype=_numpy.int32)

from setuptools import setup
from Cython.Build import cythonize

setup(
    ext_modules = cythonize("example.pyx")
)

$ python3.12 -m venv .venv
$ source ./.venv/bin/activate
$ pip install 'cython>=3' setuptools numpy
$ python setup.py build_ext --inplace
$ python -c "import example; print(example.test_mem(10))"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "example.pyx", line 8, in example.test_mem
    cpdef test_mem(size_t size):
  File "example.pyx", line 14, in example.test_mem
    cdef object buf = _memoryview.PyMemoryView_FromMemory(
AttributeError: type object 'memoryview' has no attribute 'PyMemoryView_FromMemory'

$ pip install 'cython<3' setuptools numpy
$ python setup.py build_ext --inplace
$ python -c "import example; print(example.test_mem(10))"

[0 1 2 3 4 5 6 7 8 9]

Expected behaviour
Work as prior to Cython 3.0.0 or compilation time error.
OS
Linux, MacOS, others not tested
Python version
3.12.7
Cython version
any 3.*
Additional context
No response

For reference the basic bug is also an issue in earlier versions of Cython
from cpython cimport list as _lst

def test_list():
    return _lst.PyList_New(0);

This fails similarly on 0.29.x.
The difference is that memoryview is specifically recognised as a builtin type on Cython 3+


Database pages

@bantic for you to review/merge. This is the database creation page and database show pages.

looks good. waiting for build to pass, then will merge.

bower is down again, which is why this build is now erroring. 0_0


Carthage

It's will be great to add Carthage support
You can follow this tutorial: Making Carthage-compatible Frameworks with Swift

I'll try.

I think it's working now.@TofPlay

@wangjwchn I tested. Work like a charm 👍🙂


Error when running iSAFE using haps converted using plink2

Can I run iSAFE using a vcf file on the entire chromosome?
Second, I tried to run iSafe on the haps file after converting the vcf containing phased data to haps by plink2.
But I ended up getting an error, as shown below.
File "/home/miniconda3/envs/iSafe/bin/isafe", line 10, in
sys.exit(run())
^^^^^
File "/home/miniconda3/envs/iSafe/lib/python3.12/site-packages/isafe/isafe.py", line 185, in run
total_window_size = POS.max() - POS.min()
^
TypeError: unsupported operand type(s) for -: 'str' and 'str
What could be the reason for this error?
Also, I want to scan selection loci using iSAFE on the entire chromosome without specifying a specific region. How can I use iSAFE for this purpose?
my input file looks like this

Hi,
The current implementation of iSAFE is unable to process the entire genome. Many selection scan tools, such as those listed at slescan, are designed for this purpose. However, I have addressed a similar question in https://github.com/alek0991/iSAFE/issues/6, which details how to use iSAFE for this purpose. A similar approach was used in Colomer-Vilaplana et al. 2022.
Could you please share a small example of your input along with the error so that I can replicate it?
Best,
Ali

Dear Alex, I appreciate you getting back about this me so quickly.
Yes, I was running this command per chromosome.
isafe --input  file1.hap --output   file1 --format hap, with defauty setting.
This is an error I was getting.
File "/home/miniconda3/envs/iSafe/bin/isafe", line 10, in
sys.exit(run())
^^^^^
File "/home/miniconda3/envs/iSafe/lib/python3.12/site-packages/isafe/isafe.py", line 185, in run
total_window_size = POS.max() - POS.min()
TypeError: unsupported operand type(s) for -: 'str' and 'str

My input file looks like this: ( This was obtained after converting phased vcf to haps by plink2 with little modification into  ISAFE format.

![image](https://github.com/alek0991/iSAFE/assets/73900141/0252e8bb-9b0e-448b-bbe3-14195f1d2d1a)

I am sorry my question seems to basic. I truly appreciate your assistance.

The error is occurring because the POS variable contains string values instead of numeric values, and the subtraction operation is not supported between strings. Please ensure all POS values are numeric.


Tie MSM methods to {Projective/Affine}Curve

Description
closes: #411

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (master)
[x] Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[ ] Wrote unit tests
[ ] Updated relevant documentation in the code
[x] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[x] Re-reviewed Files changed in the GitHub PR explorer

I think we should make separate traits for FixedBaseMSM and VariableBaseMSM, and then add bounds to ProjectiveCurve: FixedBaseMSM + VariableBaseMSM. This is compatible with the refactor in https://github.com/arkworks-rs/algebra/pull/294


Host-sys, control-interface and core dep cleanup

Feature or Problem
Inspired by some of the pain @joonas went through to release the last version of wash-cli
This PR:

Removes the host-sys crate, which was an initial experiment but hasn't been touched since its creation (@rvolosatovs please feel free to push back if this is serving a function somewhere
Removes unused dependencies from the control-interface and core crates.
Removes the reliance on the core crate in wasmcloud-control-interface by using Strings instead of type aliases.

Related Issues
This is related to a broader issue in this monorepo where crates are too hard to release and there's too much inter-reliance for a tiny subset of functionality. In this case, the reliance on the core crate for string type aliases created a dependency where any core crate release would also require a control interface release. There are many other changes we can make like this in the repository that don't require a lot of changes that can help us get to a point where our crates only depend on each other when there's really functionality that should be broken out and shared.
Other, not fully featured ideas to continue this trend are:

[ ] Reduce public interactions with core types so that crates can co-depend on it without needing to be on the same version
[ ] Merge wash-lib and wash-cli into wash to prevent two releases for libs and CLI crates
[ ] Combine wascap / provider-archive into wasmcloud-core as modules of the crate, or try and untangle them.

Release Information
Nothing needed urgently. This removes public re-exports from the wasmCloud control interface so, perhaps it's a breaking change we could prevent by just creating those type aliases instead of removing them.
Consumer Impact

Testing

Unit Test(s)

Acceptance or Integration

Manual Verification

Keeping host-sys as per @rvolosatovs good point that it may not be actively contributed to, but it is a C integration point that we should preserve


Timestamp to another column in another sheet

I have no idea how to do this in a reasonable way. I've now made it so users don't even put the timestamp in. This will be really tricky.
2 Problems:

I don't ask users to put in the timestamp column anymore. Not sure how to solve this one properly.
How do I support the UI for getting a column from another sheet? I could have a little button that lets you pull the info into the active input. I had something like this before, but it wasn't very intuitive.

This will be considered out of scope.


Allow for a delay prior to the DNS precheck

This requires the challenge objects to be able to group authorizations by the order that spawned them, so that waiting isn't done per authorization, but per order (and only once per order), as all of an order's PreSolve steps are done before all of its Solve steps.  This leads to an acme.ExtendedAuthorization object which has a handle to the acme.ExtendedOrder, but then requires threading throughout the code.
This gives me what seems to be a usable workaround for the Google Cloud DNS issue in #770, which is to have a two-minute delay between PreSolve() and the precheck. This seems to have a significantly lower failure rate than simply running the precheck repeatedly until it succeeds multiple times in a row (in fact, it has a 0% failure rate in my experiments once nonce errors and presolve-stage errors are taken into account).
The ExtendedAuthorization type and its threading throughout isn't ideal, IMO, but something similar would be required regardless. My initial naive implementation simply slept the entire delay duration inside preCheck.call(), but that meant that every time through was a long sleep, and the propagation timeout could trigger. Pulling it out of the loop and into Challenge.Solve() directly helped, but that slept between solves of different authorizations from the same order, which shouldn't be necessary, since they all were told to propagate at the same time. But a single solveAt stashed in the preCheck object gets reused for all orders from the same client, so that wouldn't work for more than very simple examples.
Having the Order object available might make #771 fixable, too.

It's a breaking change of the API, I will prefer a less invasive modification.

I don't see how it is. The token needs to be the same across all authorizations of the same order; Authorization.Identifier is unique to that authorization.
The only other thing I've been able to sketch out is to add a way to pass the mapping between Authorization and Order into the Prober object, so that it can delay between PreSolve() and Solve(). But that would mean either changing the Prober.Solve() signature (and thus that of certificate.resolver.Solve()) or by introducing a new interface next to certificate.resolver that allowed for this. I think the latter would be non-breaking.

Any changes of the any exported function signatures are a breaking changes of the API lib.
But we can create a breaking change if needed.
For me the ExtenddAuthorization is not needed.
A change of the signature of the method Solve is enough (Solve(order, authz)).
Several remarks:
solveAt map[string]time.Time:

as the precheck is a singleton, solveAt is a singleton.
it's a map so it's an issue with concurrent calls.
as it's a singleton, the entry must be clean after the process.

The algo to apply the precheck delay can be simplify: because the delay need to be apply once we don't need to use a Time and we don't need to compute a time.Until() for each iteration.
As the the order is an ExtendedOrder you can use the Location as UID.
FYI:

ACME draft Section 7.4 "Applying for Certificate Issuance"
https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.4
says:
Clients SHOULD NOT make any assumptions about the sort order of
"identifiers" or "authorizations" elements in the returned order
object.

The algo to apply the precheck delay can be simplify: because the delay need to be apply once we don't need to use a Time and we don't need to compute a time.Until() for each iteration.

I would moderate this sentence due to parallelSolve

Could you explain your last changes?
Why have you move the delay from challenge.Solve to parallelSolve?
Why only parallelSolve and sequentialSolve?

As I was working through the problem again, it occurred to me that all I really needed was to have all of the PreSolve() calls finish, then do the sleep, then make all the Solve() calls—that's the definition of what I need. Since Prober.Solve operates on a single order, it allows me to not need the whole Authorization/Order mapping, and eliminates the concurrency issues with the map. But it means that now the Challenge needs to be able to communicate the delay time back to this piece of the code.
All in all, it seemed simpler to me. I did forget to update sequentialSolve(), though.
I can put the sleep back in the Challenge if you prefer, or I can keep it as is and update sequentialSolve().

No worries.  I was also playing with another change that added a function to wrap the precheck function, giving me the possibility to add some pre- and post-processing (I wanted to call precheck multiple times to make sure it returned consistent results, but that didn't help the way I thought it would).
Originally I thought I could do the delay with that, then realized I couldn't because it would sleep every time. Now I finally realized if the wrapper closed over solveAt, then I can keep all the metadata I need outside of lego. I still need something like the Authorization/Order mapping, but I get by with the domains: I keep a map of all the domains in an order to to a unique token when I create the order, and extract the token using the domain, which I'm now passing to the call() method on the preCheck object.
I can submit that as a separate pull request, along with sample code, if you'd like to see it.

Closed in favor of #783


use pyimport_conda

As of PyCall 1.5, you can now just do pyimport_conda("serial", "pyserial") to auto-install pyserial via Conda (if PyCall is using Conda) or print an informative error message, rather than duplicating that logic here.   This will also let you remove the explicit Conda dependency.

Excellent, thanks for letting me know!


Should kubectl-gs template commands do validation

Related to https://github.com/giantswarm/giantswarm/issues/20848.
Description
As an overarching issue for the above linked issue, we should discuss whether kubectl-gs commands should perform any validation (e.g. within template commands).
TODO

[ ] Bring it to KaaS sync

closing


Cannot read property 'getView' of undefined

Description
I get an error with the title and description listed below, on an html file.  There might be a possible missing closing tag somewhere, which was why I wanted to run beautify to help find out where.
OSX 10.11.15 w/ Atom 1.9.0-dev-38ff433
Expected Results
I expected pretty code, perhaps even beautiful code (well, at least on how it is visually structured).
TypeError: Cannot read property 'getView' of undefined
    at getScrollTop (/Users/alice_em/.atom/packages/atom-beautify/src/beautify.coffee:31:29)
    at beautifyCompleted (/Users/alice_em/.atom/packages/atom-beautify/src/beautify.coffee:108:27)
    at tryCatcher (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:502:31)
    at Promise._settlePromise (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:559:18)
    at Promise._settlePromise0 (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:604:10)
    at Promise._settlePromises (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:683:18)
    at Async._drainQueue (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:138:16)
    at Async._drainQueues (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:148:10)
    at Async.drainQueues (/Users/alice_em/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:17:14)

Steps to Reproduce

Add code to Atom editor
Run command Atom Beautify: Beautify Editor
This beautified code does not look right!

Debug
Here is a link to the debug.md Gist: ( https://gist.github.com/alice-em/b27b1e4b59c969e935e0d1c01fae370d ) (it ain't pretty)
How to create debug.md Gist
Note that this will include a copy of your code.
If your code is private, please create a different sample of code that reproduces the problem.

In the Atom command-palette,
search for and run the command Atom Beautify: Help Debug Editor.

The debugging results will be copied to your clipboard.
2. Create a new Gist at https://gist.github.com/
3. Create a file in your new Gist called debug.md.
4. Paste your debugging results from Atom beautify into debug.md file in your Gist.
5. Add a link to your Gist in your new Issue.
https://gist.github.com/alice-em/b27b1e4b59c969e935e0d1c01fae370d
Checklist

[x] I have tried uninstalling and reinstalling Atom Beautify to ensure it installed properly
[x] I have reloaded (or restarted) Atom to ensure it is not a caching issue
[x] Searched for existing Atom Beautify Issues at https://github.com/Glavin001/atom-beautify/issues
so I know this is not a duplicate issue
[x] Generated debugging information and added link for debug.md Gist to this issue

Atom 1.9.0-dev-38ff433

It may be an unsupported Atom API with your version of Atom. I am on v1.7.3.
Unfortunately, I don't have time to investigate. If you do find a solution feel free to submit a Pull Request. Thanks!

I think it might be tied to 1.9.0-dev.  I'm on my Ubuntu machine testing between 1.7.3 and 1.9.0-dev-896abe3, and it works with 1.7.3, but fails with 1.9.0-dev.

Same here on 1.9.0-dev-720ad9c

https://github.com/Glavin001/atom-beautify/pull/987 has been merged. Awaiting a few other Pull requests to be merged and then will publish a release!

I am also experiencing the error. I am running the latest master branch of the atom git repo, version 1.10.0-dev-f6e87b1 on Arch Linux. I am trying to beautify a JavaScript file but this error occurs and the file is not modified at all. Hopefully this fixes the problem when v0.30.0 is released.
TypeError: Cannot read property 'getView' of undefined
    at getScrollTop (/home/ayrton/.atom/packages/atom-beautify/src/beautify.coffee:31:29)
    at beautifyCompleted (/home/ayrton/.atom/packages/atom-beautify/src/beautify.coffee:108:27)
    at tryCatcher (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:502:31)
    at Promise._settlePromise (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:559:18)
    at Promise._settlePromise0 (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:604:10)
    at Promise._settlePromises (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/promise.js:683:18)
    at Async._drainQueue (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:138:16)
    at Async._drainQueues (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:148:10)
    at Async.drainQueues (/home/ayrton/.atom/packages/atom-beautify/node_modules/bluebird/js/release/async.js:17:14)

Published to v0.29.8


Check to see if parentBlock can be moved to viewState rather than malcolm state

The parentBlock, childBlock and mainAttribute properties seem like they should naturally go on the view state object. Check if they are being used by the malcolm code and if not then move them, at the least they should be grouped together as an object.

The answer to this is no, it is required by a lot of the malcolm reducers to know which block is being operated on


Split chunks are not being loaded in the webworker target

Bug report

What is the current behavior?
The chunks are not imported (no occurrences of importScripts in entry chunks) so an error is thrown:
Uncaught TypeError: Cannot read property 'call' of undefined        worker-a.js:20
__webpack_require__ @ worker-a.js:20
(anonymous) @ worker-a.js:93
__webpack_require__ @ worker-a.js:20
(anonymous) @ worker-a.js:84
(anonymous) @ worker-a.js:87

If the current behavior is a bug, please provide the steps to reproduce.
Repo: https://github.com/Alexendoo/bugs/tree/master/02-webpack-worker-chunks
Hosted: https://alexendoo.github.io/bugs/02-webpack-worker-chunks/ (nothing to display, just the errors in console)
The above setup has two entries, worker-a and worker-b that have a common shared dependency on shared.js, it sets minSize: 0 and chunks: "initial" in splitChunks to force a separate chunk to be created
The output of running webpack can be seen in dist/, neither worker-a.js nor worker-b.js import worker-a~worker-b.js
The bug also occurs when adding a named chunk to cacheGroups
What is the expected behavior?
Both worker-a.js and worker-b.js should import the chunk in worker-a~worker-b.js, through importScripts or some other mechanism
Other relevant information:
webpack version:  4.16.5
Node.js version: 10.7.0
Operating System: Windows 10
Additional tools: none

Yes, splitting the initial chunks is (currently) not supported in WebWorkers. You must provide chunks: "async".
To get some kind of deduplication you could use import() in the entrypoints.

I see, thanks @sokra!

facing the same problem

I am using
optimization: {
    splitChunks: {
      cacheGroups: {
        commons: {
          chunks: 'all',
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
        }
      }
    }
  }

does seem to load the vendors chunk

.

Any news on this? I have the exact same problem. But with node modules.  The answer from @prateekbh does not fix it, I get the error
bootstrap:19 Uncaught TypeError: Cannot read property 'call' of undefined at r (bootstrap:19) at Module.<anonymous> (webworker1.js:1) at Module.131 (webworker1.js:8) at r (bootstrap:19) at bootstrap:83 at bootstrap:83

On my side, I'm using import _ from 'lodash in my worker. It does work but instead of loading the lodash chunk (using importScript) that was generated by the main app, it copies the full lodash codebase inside my worker file. That is a shame since it's making a 13kb worker into a 1.3 Mb one!

I never had an anwer @dannibje 😛

This is still a real issue even if it's inactive. I don't understand this bot. I never knew waiting issues out was a way to fix them ! :stuck_out_tongue:

will it support in webpack 5?

This is still a real issue even if it's inactive. I don't understand this bot. I never knew waiting issues out was a way to fix them ! :stuck_out_tongue:

We can't fix everything. Piling up issues neither fixes them.
But anyway this is fixed in webpack 5


Add Cask for ctop 0.7

https://ctop.sh/
I've been using my own tap, but the owner of the project also thinks it's interesting to have it here on the official repos.
https://github.com/bcicen/ctop/pull/118
After making all changes to the cask:

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

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

This already exists in Homebrew.
https://github.com/Homebrew/homebrew-core/blob/master/Formula/ctop.rb

This is our policy for cli open source binaries.

Rejected Casks
The app is both open-source and CLI-only (i.e. it only uses the binary artifact). In that case, and in the spirit of deduplication, submit it first to Homebrew/core. If it is rejected there, you may then try again in Homebrew-Cask (link us to the issue on Homebrew so we can see their reasoning for rejection).

So, having a ready to consume, dependency free version is not interesting for Homebrew Cask?

ready to consume, dependency free

The formula only has build deps.

Right!
Personally, I choose not to install go using brew, and having a second installation of go in my machine just to build binaries that depend on go is really troubling.
I would love to think of Cask as a tool that would help me download the binaries and link them directly. Is this not a goal of the project? 🤔

Personally, I choose not to install go using brew, and having a second installation of go in my machine just to build binaries that depend on go is really troubling.

If you build from source that is your choice, it isn't the default.

I would love to think of Cask as a tool that would help me download the binaries and link them directly.

We don't duplicate Homebrew formula unless it's for a very good reason (and this isn't one).

Wow, I'm feeling very dumb now. I was sure there was no bottle option, but even then I should have added it myself there instead of building a cask.
🤦♂
Sorry


Add tf.contrib.data.LMDBDataset support

This fix tries to address the issue raised in #21129 where
there was no LMDBDataset support (only LMDBReader).
This fix fixes #21129.
Signed-off-by: Yong Tang<EMAIL_ADDRESS>

tentatively assigning this to @jhseu

Derek, thoughts on tf.contrib.data or tf.data for this? We already have LMDBReader in TensorFlow because it's a common format used with Caffe.

Thanks @mrry for the review. The PR has been reworked and now LMDBDataset is exposed through tf.contrib.data. The binary file data.mdb has also been removed. I take a look at the mdb library but couldn't find an easy way to pass different stream than filename. Please take a look.

Nagging Assignee @caisq: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.


Nested actors cause weird error

actor Demo {
    actor otherActor {
    }
}

causes
type error [M0038], misplaced await

The message is totally misleading, since the await is not syntactical, but implicit (creation of otherActor). But at that actor-global context await is forbidden.

Maybe we can discover the implicitness by looking at the source location (or adding another annotation).
On the other, hand we don't really support this on the IC, so I'm less worried about it.

I am also not worried. Maybe inspecting the AST node to spot the actor Name-style binding would give us the criterion for a better error message.


Several fixes/tweaks to DDASLLogCapture.

Several tweaks to DDASLLogCapture.
First, -stop was not working, because a bad token value was used to cancel.  Either the notifyToken value should be declared __block, or the token parameter in the block argument should be used (I did the latter).  Currently, the initial value of 0 is just captured by the block, and is using that to cancel, which doesn't work.
Should use asl_free instead of free I believe, and it should go before the cancel return statement else that would be a leak when stopping.
I don't think there is a need to avoid the log when a timestamp is not provided; so I changed to just use the current time in that situation.
Use "self" instead of a hardcoded class name; that can help if subclassing or copying code to a clone class, if needed for some reason (perhaps to add some DDLogMessage state based on certain log messages, to aid custom formatters).
Fixed "Received" misspelling.
Lastly, creating ObjC objects when not necessary is extremely slow, and should be avoided if possible in a low-level framework like logging.  It is possible for log messages to be flooded and the log framework overhead should be kept minimal.  In this case, several NSStrings were created just to parse numbers out of them, which can be done with C API functions.

:+1:

Looks great except for the Travis maybe unrelated error here.

Considering those tests don't invoke DDASLLogCapture at all, those would be unrelated.  Really, I don't think those tests are safe to be async.  You see logs from previous tests getting intermingled with that last test which failed.  It looks one test could still be executing, then a new test instance can be created which calls DDLog removeAllLoggers and installs a new one, and if the background thread for the previous async DDLogDebug() etc. had not started yet, the new test's logger will be the one to get the logs.  You would probably be better off making them all synchronous and using DDLog flush as the first thing in -setUp, and then again at the end of the test.

I run Travis in master to be sure, and it passed. Which is weird.
The thing is if we break Travis we can't safely merge subsequent pull requests.

I don't think it's weird... the tests themselves need to be fixed.  As I see it right now, it depends on thread execution order.  The global list of loggers is not something you can easily use with async tests -- they can conflict with each other.  If one test routine ends, and the next one happens to begin (and call -setUp) before the DDLogDebug() call has fully filtered down to the loggers (which involves two separate background queues), then the logger from the previous async test gets removed before the logs get to it, and get passed to the next test's logger instead.  I think there are other pull requests with spurious failures too, for the same reason -- nothing to do with the PRs.  So yes, there probably needs to be a commit which fixes the tests first.

I still  think this is weird. Why this commit would change the execution order this way?
Just merged #514, which as master, doesn't have this execution order problem.

It wouldn't.  This code is not invoked during the unit tests at all, so it cannot have any effect.  While the tests at first blush look OK, in the errors in Travis above, it's pretty clear that logs sent from one unit test were not delivered to loggers until another unit test's logger had been put in instead.   It sure looks like some tests are being run in parallel, or at least the -setUp method on one of them is getting called while another test is still going.  It feels like a race condition, which will often but not always work.  #497 and #499 also seem to have unrelated Travis failures for similar reasons.

OK, I think I see what is happening.  testLoggerLogLevelAsync puts in a logger which only handles Errors and Warnings, then fires off five logs (expecting that only two get through).  However, the expectations are set up that they are fulfilled once the expected number of logs come across, and the logs in that test are ordered Error-Warning-Info-Debug-Verbose.  Thus, it is entirely possible that the Error and Warning logs get handled and sent to the logger, which then fulfills its expectation, with the three subsequent logs still waiting to be processed by the queues.  Since the expectation is filled, the test ends, and the testX_ddLogLevel_async starts which removes the old logger and puts in its own, which is only expecting Error-Warning-Info logs.   Nothing calls DDLog flush first to clear out the existing ones, so then the Debug and/or Verbose logs from the previous test get sent to the new logger and cause errors.
At the very least, I would put a call to [DDLog flush] right after [DDLog removeAllLoggers] but before adding a new logger in the -setUp code.  That should clear out any pending log messages to avoid them polluting the new test.
Second, some of those tests really aren't checking to see if unexpected logs get delivered -- they are ending as soon as they see the expected ones.  You could either change the order of the logs in those case (put the unexpected-to-see ones first, so they will cause errors), and it probably would also be a good idea to call [DDLog flush] in the test cases themselves (after the expectation) then validate the number of logs actually delivered to the logger.  I don't think it's doable with the expectation fulfill logic alone, since it would have no idea if invalid logs were still in flight or not.   I don't think the use of expectations is really required -- you could probably just replace those with [DDLog flush].

The race condition making some tests fail occurred on master after @rivera-ernesto merged #514.
https://travis-ci.org/CocoaLumberjack/CocoaLumberjack/builds/63171538

The second thing is that I'm not sure that the local ddLogLevel global variable in the unit test is being used at all.  That should have prevented the final Debug/Verbose logs from ever getting to the TTYLogger, but it sure looks like those are still there.  Looking at DDLogMacros.h, either LOG_LEVEL_DEF or ddLogLevel needs to be explicitly #defined otherwise the macros use a hardcoded DDLogLevelVerbose.  I do not see that the unit tests #define anything before importing CocoaLumberjack.h.   CocoaLumberjack 1.x would just assume that the ddLogLevel variable was global and available, but no longer.  You would have to do something like #define ddLogLevel ddLogLevel or something before importing the header, I think, to make the current unit test actually work.  However, given the ordering of the logs, the last test would usually complete with a pass before the unexpected logs are actually delivered.  The test might complete though, and deallocing the mocks probably removes the stubbed methods on the original object, so even if the logger is left in the global logger list by the last test, it is an empty DDAbstractLogger instance which normally does nothing.  I suspect more issues will happen on OSX, since on multiprocessor machines the delivery to the individual loggers all happen on concurrent individual threads, while on single processor it is all synchronous on the central logger queue's background thread, with the loggers invoked serially.

The race condition making some tests fail occurred on master after @rivera-ernesto merged #514.

https://travis-ci.org/CocoaLumberjack/CocoaLumberjack/builds/63171538

Which is again weird because both master and #514's Travis builds were succeeding.
Let's merge this and then fix the unit tests.