Add backwards compatible support for fmt::Write

Hello, first thank you for all the work on this lovely library! ❤
I am submitting this PR for discussion and learning more than I am trying to get it actually merged
Implementation
This resolves https://github.com/time-rs/time/issues/375 by adding a compatibility layer between fmt::Write and io::Write. And switching the formatting machinery to use fmt::Write.
Rationale
The reason for picking fmt::Write as the canonical implementation is because of this quote from Rust fmt::Write doc page:

This trait only accepts UTF-8–encoded data and is not flushable. If you only want to accept Unicode and you don’t need flushing, you should implement this trait; otherwise you should implement std::io::Write.

Since we only want to accept UTF-8 (Is this assumption correct?) and we don't need flushing (couldn't find any calls to .flush() in the codebase) it felt more correct to use fmt::Write.
Also since fmt::Write has more guarantees (i.e UTF-8) it's easier to implement fmt::Write for io::Write than the other way around.
Uncertainties

I wasn't really sure what to call the new methods so I went with this suggestion https://github.com/time-rs/time/issues/375#issuecomment-978872293.
Same thing for the sealed internal methods, I went with renaming to format_into_old but I can keep the names of internal methods matching the names of externals methods.

Possible follow-ups

We can add a SafeLiteral(&str) to FormatItem. We should also be able to update the macros and runtime parsers to use that instead of Literal(&[u8]).
If you think this is PR is a good idea, it's up to you to decide whether you want to keep support for both Writes for foreseeable future or to deprecate the support for io::Write to be removed in a future breaking change. (Could also deprecate Literal in favor of SafeLiteral in parallel)

Tell me what do you think and if you think this is taking a completely wrong dimension please don't hesitate to close it!
Thank you ❤

Hey there. Sorry about the delay in getting to this. Would you mind rebasing? The conflict is just due to a dependency upgrade and is trivial. The other thing I immediately see is that the error branches aren't covered; could you do this? std::fmt::Error is publicly a ZST so it shouldn't be difficult to construct a case that covers this.
Once these two things are done I'll do an in-depth review and merge if appropriate.

Oh, and assuming that the bytes are UTF-8 is not an assumption that should be made. It is currently possible to construct a FormatDescription manually with raw bytes, and I believe that there are tests that rely on this. I'm 99% certain there are real-world users that need this behavior too.

Hey there. Sorry about the delay in getting to this. Would you mind rebasing? The conflict is just due to a dependency upgrade and is trivial. The other thing I immediately see is that the error branches aren't covered; could you do this? std::fmt::Error is publicly a ZST so it shouldn't be difficult to construct a case that covers this.
Once these two things are done I'll do an in-depth review and merge if appropriate.

No worries! Happy new year ❤
Fixed conflict and covered fixed coverage

Oh, and assuming that the bytes are UTF-8 is not an assumption that should be made. It is currently possible to construct a FormatDescription manually with raw bytes, and I believe that there are tests that rely on this. I'm 99% certain there are real-world users that need this behavior too.

Yeah it looks like my assumption was indeed in correct, I was able to observe different behaviors using this test case
use time::format_description::FormatItem;
use time::macros::date;

const NON_UTF8: &[FormatItem<'_>] = &[
    FormatItem::Literal(&[195, 40]),
];

fn main() {
    let today = date!(2022 - 01 - 03);

    let mut bytes = vec![195, 40];

    dbg!(today.format_into(&mut bytes, NON_UTF8));
    dbg!(bytes);
}

On main branch this produced [195, 40, 195, 40] but on this branch it produces [195, 40, 239, 191, 189, 40] so this isn't mergable as-is.
One possible solution is to reverse the roles and implement io::Write for fmt::Write like this:
struct Compat<'a, W: fmt::Write> {
    writer: &'a mut W,
}

impl<'a, W> io::Write for Compat<'a, W>
where
    W: fmt::Write,
{
    fn write(&mut self, buf: &[u8]) -> io::Result<usize> {
        let string = String::from_utf8_lossy(buf);

        self.writer
            .write_str(&string)
            .map(|_| string.len())
            .map_err(|_| io::Error::new(io::ErrorKind::Other, "Internal fmt error"))
    }

    fn flush(&mut self) -> io::Result<()> {
        Ok(())
    }
}

But this can be done in userland so I am not really sure if there's any benefit to including it here.
One other possible solution is for the Sealed trait to require a manual implementation for format_into and format_into_fmt_write where they'd be pretty much identical implementations except for behavior around FormatItem::Literal but that seems like a lot of duplicate code to keep around.
So I am not sure if there's anything here that's actionable for time crate anymore, should I close this?

But this can be done in userland so I am not really sure if there's any benefit to including it here.

Well, it's been requested a few times so there's some benefit in just doing it once so others don't have to. It's not like it's out of scope or anything.

One other possible solution is for the Sealed trait to require a manual implementation for format_into and format_into_fmt_write where they'd be pretty much identical implementations except for behavior around FormatItem::Literal but that seems like a lot of duplicate code to keep around.

Wouldn't the only place that would need to be changed be impl<'a> sealed::Sealed for FormatItem<'a>? That is the implementation that everything ultimately falls back on. If this is the case it's not that much code to duplicate: just a dozen lines or so. Well-known types can be passed through String::from_utf8 (matching and using unreachable!("…") on the result), as the formats are known to be UTF-8 in their entirety.
My thought right now (having largely not reviewed the approach you actually took) is to create a private trait that any type implementing io::Write or fmt::Write implements. All internal APIs can then be made generic over that trait. Right off the top of my head I think this might run into a currently unsolvable problem, though: a type can implement both io::Write and fmt::Write and specialization is not stable. If this is in fact the case, then altering the aforementioned implementation is probably the way to go unless I'm missing something?

Wouldn't the only place that would need to be changed be impl<'a> sealed::Sealed for FormatItem<'a>? That is the implementation that everything ultimately falls back on. If this is the case it's not that much code to duplicate: just a dozen lines or so. Well-known types can be passed through String::from_utf8 (matching and using unreachable!("…") on the result), as the formats are known to be UTF-8 in their entirety.

This made me realize that there was actually a path forward within the current implementation, I pushed it in the latest commits alongside a test to verify that it works (and that it indeed did fail before the changes)

My thought right now (having largely not reviewed the approach you actually took) is to create a private trait that any type implementing io::Write or fmt::Write implements. All internal APIs can then be made generic over that trait. Right off the top of my head I think this might run into a currently unsolvable problem, though: a type can implement both io::Write and fmt::Write and specialization is not stable.

I am not entirely sure how would this look, could you elaborate on it? I agree that this sounds like something that would quickly hit specialization though

I am not entirely sure how would this look, could you elaborate on it?

Basically it would require all internal methods like format_number to be generic over a trait that shims the two writers into a desired API. I'm quite certain it's not currently possibly, though.
I'll take a look at the code soon™

Finally coming back around to this. After some more thought, I don't think that this is the best way forward. Duplicating methods has some overhead from the user's perspective, as you need to know which to call — and they're split for no apparent reason to someone new to or unfamiliar with Rust. In addition, the compatibility is ultimately a hack. While possible to avoid, doing so would lead to significant duplication as noted earlier in this thread.
For these reasons (along with minor nits), I'm going to close this. I sincerely thank you for your work on this; it's not trivial to do. Your work is appreciated even though this PR is not ultimately being merged.
Looking forward, I think specialization will lead to the ideal solution here. Being able to accept either io::Write or fmt::Write is clearly preferable, and having the ability to prefer io::Write when a parameter implements both would be great. This would be wholly transparent to the user, and would avoid some of the concerns introduced here. To my knowledge min_specialization is sound and may be stabilized later this year. Full specialization is not needed here.

Sounds good! And thank you for your time ❤ Looking forward to specialization stabilization as well


Improve mobile styling for the presets panel button group

This patch fixes the styling for the buttons in the preset panel
Here's how it looks now:

Compared to before:

Okay maybe using flex-grow was a bad idea (it looks like a masonry ui). Maybe I should just remove the original space-between property ?
it doesn't look so bad on desktop:

or mobile:

I think we want to keep space-between on desktop for sure, it results in a more balanced UI -- maybe use a media query so you're only removing it on mobile viewports?


delete/unselect scribbles

Feature request:
A button allowing the user to unselect (for example, right clicking to erase some annotation region) would help tuning more finely the results. Alternatively, if we can do undo for more than once, that would be great also.

More undos and redos of annotations are added to branch for version 1.5


Добавить US

[ ] for Upgrade
[ ] for CSS setting
[x] for move to back/front - created US-4-6 (https://jdi-family.atlassian.net/wiki/spaces/JDN/pages/24772609/US-4-6+Moving+highlited+objects+to+back+to+front)
[x] update US-7-3

These tasks are added to #186


Support of AlwaysOn VPN in a Cluster

Hi Team
This documentation seems to be specific for DirectAccess, if there similar documentation on how to do with for AlwaysOn VPN?
Thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c7588744-e1a1-7038-d9e1-da15da049176
Version Independent ID: 41df6ff7-603e-3b37-e05a-fc79e9565a03
Content: Plan a Remote Access Cluster Deployment
Content Source: WindowsServerDocs/remote/remote-access/ras/cluster/plan/Plan-a-Remote-Access-Cluster-Deployment.md
Product: windows-server
Technology: networking-ras
GitHub Login: @eross-msft
Microsoft Alias: lizross

Please see https://social.technet.microsoft.com/Forums/windowsserver/en-US/60346461-2c23-44e3-8204-228e85ddefdf/high-availability-for-always-on-vpn?forum=winserverNIS#9186e914-310b-4896-aa98-71040b7bde8a

#assign:IngridAtMicrosoft

Addressed in comments.


We need guidance for Codespaces

The devcontainer readme has important information in it about how to run the workbench in the Codespaces environment. We should provide some central guidance about using Codespaces and make sure it is referenced throughout setup instructions.
This should also cover using local devcontainers.

@robotdad - I updated that readme with more info regarding Codespaces in general, would you like to add any additional contents for local devcontainers to it?

That's great! Thanks. I can take a future pass on something for local devcontainers.


Feature Request: more flexibility in saving output

Currently, CmdStan saves output relative to the package directory.  For example:
ProjDir = Pkg.dir("Stan","Examples")# Julia .6 syntax
cd(ProjDir)
...
stan(stanmodel, Data, ProjDir=ProjDir, ...)

This is somewhat inconvenient because it seems to require changing the directory and saving the output deep in the file system. It would be nice to specify any location such as:
ProjDir = "/myFolder/mySubFolder/"
...
stan(stanmodel, Data, ProjDir=ProjDir, ...)

Thanks for your consideration.

Chris,
on my system, OSX, below script works fine. This .jl file can be anywhere but it does expect the ProjDir to exists
######### CmdStan program example  ###########

using CmdStan, Test, Statistics

ProjDir = "/Users/rob/Documents/"
cd(ProjDir) do

  bernoullimodel = "
  data {
    int<lower=1> N;
    int<lower=0,upper=1> y[N];
  }
  parameters {
    real<lower=0,upper=1> theta;
  }
  model {
    theta ~ beta(1,1);
    y ~ bernoulli(theta);
  }
  "

  observeddata = [
    Dict("N" => 10, "y" => [0, 1, 0, 1, 0, 0, 0, 0, 0, 1]),
    Dict("N" => 10, "y" => [0, 1, 0, 0, 0, 0, 1, 0, 0, 1]),
    Dict("N" => 10, "y" => [0, 0, 0, 0, 0, 0, 1, 0, 1, 1]),
    Dict("N" => 10, "y" => [0, 0, 0, 1, 0, 0, 0, 1, 0, 1])
  ]

  global stanmodel, rc, sim, cnames
  stanmodel = Stanmodel(num_samples=1200, thin=2, name="bernoulli",  model=bernoullimodel);

  rc, sim, cnames = stan(stanmodel, observeddata, ProjDir, diagnostics=false,
    CmdStanDir=CMDSTAN_HOME);

  if rc == 0
    @test round.(mean(sim[:, 8, :]), digits=1) ≈ 0.3
  end

end # cd

Does that work on your system as well?

Unfortunately, it does not work. As you can see the target directory exists.
dfish@dfish-MS-7850:~/Projects$ '/home/dfish/julia.7/bin/julia'
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: https://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.7.0 (2018-08-08 06:46 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/                   |  x86_64-pc-linux-gnu

julia> using CmdStan, Test, Statistics

julia> ProjDir = "/home/dfish/Projects/Stan Output"
"/home/dfish/Projects/Stan Output"

julia> cd(ProjDir) do

         bernoullimodel = "
         data {
           int<lower=1> N;
           int<lower=0,upper=1> y[N];
         }
         parameters {
           real<lower=0,upper=1> theta;
         }
         model {
           theta ~ beta(1,1);
           y ~ bernoulli(theta);
         }
         "

         observeddata = [
           Dict("N" => 10, "y" => [0, 1, 0, 1, 0, 0, 0, 0, 0, 1]),
           Dict("N" => 10, "y" => [0, 1, 0, 0, 0, 0, 1, 0, 0, 1]),
           Dict("N" => 10, "y" => [0, 0, 0, 0, 0, 0, 1, 0, 1, 1]),
           Dict("N" => 10, "y" => [0, 0, 0, 1, 0, 0, 0, 1, 0, 1])
         ]

         global stanmodel, rc, sim, cnames
         stanmodel = Stanmodel(num_samples=1200, thin=2, name="bernoulli",  model=bernoullimodel);

         rc, sim, cnames = stan(stanmodel, observeddata, ProjDir, diagnostics=false,
           CmdStanDir=CMDSTAN_HOME);

         if rc == 0
           @test round.(mean(sim[:, 8, :]), digits=1) ≈ 0.3
         end

       end # cd
=====> /home/dfish/Projects/Stan Output

File /home/dfish/Projects/Stan Output/tmp/bernoulli.stan will be updated.

An error occurred while compiling the Stan program.

Please check your Stan program in variable 'bernoulli' and the contents of /home/dfish/Projects/Stan Output/tmp/bernoulli_build.log.

ERROR: Return code = -3
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] #stan#4(::Type, ::Bool, ::Bool, ::String, ::Function, ::Stanmodel, ::Array{Dict{String,Any},1}, ::String) at /home/dfish/.julia/packages/CmdStan/CmHPf/src/main/stancode.jl:106
 [3] (::getfield(CmdStan, Symbol("#kw##stan")))(::NamedTuple{(:diagnostics, :CmdStanDir),Tuple{Bool,String}}, ::typeof(stan), ::Stanmodel, ::Array{Dict{String,Any},1}, ::String) at ./none:0
 [4] (::getfield(Main, Symbol("##3#4")))() at ./REPL[3]:27
 [5] cd(::getfield(Main, Symbol("##3#4")), ::String) at ./file.jl:96
 [6] top-level scope at none:0

julia> ^C

julia> isdir(ProjDir)
true

What is in the "Stan Output/tmp" dir?

Could you also try without a blank in the path, e.g. StanOutput?

I can reproduce the Return code = -3 error with a blank in the path name. The Julia side is ok with that, the Stan executables or make step might not.

dfish@dfish-MS-7850:~/Projects/Stan Output/tmp$ ls
bernoulli_build.log  bernoulli.stan
dfish@dfish-MS-7850:~/Projects/Stan Output/tmp$
dfish@dfish-MS-7850:~/Projects/Stan Output/tmp$

The build file reads:
make: *** No rule to make target '/home/dfish/Projects/Stan Output/tmp/bernoulli'.  Stop.
It works when I remove the space. Evidently, its not parsing it correctly.

Good catch!

I'm fine with removing spaces. The only downside is that others may occasionally encounter this error

This might be a constraint the Stan folks had to accept to cover Windows or R? Not sure if I can fix that without modifying their setup. I can certainly ask Bob.
Now the important question is, in your issue you mention 'deep in the file system' is that still true if you can run it from  ~Documents or ~Projects/Stan?

I'll expand the error message for Error code = -3 to al least include a hint to look for this issue.


Unable to install package on Linux

I am unable to install the package using (apm install atom-beautify) the console freezes and I am also unable to install using atom gui.

Travis CI is passing and is Ubuntu (Linux): https://travis-ci.org/Glavin001/atom-beautify
Any errors for you?

No errors, I have bad internet and I am behind a company firewall that could explain why


Warnings shown when embedding wrapper child components

Hi again,
This is not really an issue but more of an opinion. I've noticed some warnings are being shown when embedding "invalid" child elements into some components. Something like:
Warning: Failed prop type: "MyMessage" is not a valid child for MessageList. Allowed types: Message, MessageGroup, MessageSeparator, MessageListContent

My issue here is that this warning is shown if I try to wrap my components for custom logic or even just for cleaner code. For example, the following component would throw this warning.
const MyMessage = (props: MessageProps) => {

    const {} = props;

    //some custom logic here

    return (
        <Message {...props} />
    );
};

Are these warnings shown on the production build as well? Or only the dev build?
Thanks!

Another heads up that may be related to this @supersnager. I noticed that when I build for production, it looks like the custom components I have do not show up. I created separate components for my conversation header and input container of my chat.
The dev build looks like:

Whereas the production build shows:

Any ideas? I feel like the components may be doing something wonky with the getChildren function and Typescript may be having some issues with it.

Hey @nzayatz14,
it's difficult to say without the code, but I have some suspicions.
If you are using the as parameter with the type:
as={ConversationHeader}

try to use a string instead:
as="ConversationHeader"

I actually passing the string currently. Heres a skeleton of my component
<ChatContainer>
    <ChatHeader
        as='ConversationHeader'
       //other props
    />

    //MessageList and messages

    <ChatInputToolbox
        as='InputToolbox'
        //other props
    />
</ChatContainer>

@nzayatz14 How you build your app for production? You are using CRA or something else?

Yes, just using create-react-app so pretty standard I'd imagine. Also heres my tsconfig if this helps
{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "noFallthroughCasesInSwitch": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",
    "baseUrl": "."
  },
  "include": [
    "src"
  ]
}

@supersnager so after digging into this a bit, it looks like your getChildren function is relying on the code to not be minified. However, the ConversationHeader and InputToolbox get minified on the production build, whereas the MessageList and MessageInput components do not. I believe this has something to do with MessageList and MessageInput being class based and ConversationHeader and InputToolbox being function based components.
Heres an example of the minified vs unminified classes:
Minified ConversationHeader component:

Non-minified MessageInput component:

So, in your getChildren function when you are looping through the types to get the strTypes here:
var strTypes = types.map(function (t) {
    return t.name || t.displayName;
  });

Your result is not quite what you'd expect:

Not sure how you want to move forward with this information, but what I've seen from most packages that have specified child props is they will throw a warning on the development build saying something like This is not a valid child element of MyComponent, expecting MyChildComponent or MySecondChildComponent. But on the production build, they will just ignore it and let it happen, not remove items that are not "supposed to be there."
Hope this helps

@nzayatz14 Please check the 1.8.1 version, and let me know if it works for you.

@supersnager this appears to fix the production build issue, thanks!


"Install rr" dialog pops up on Windows each time VSCode is launched

IIUC, there's no way of running rr/midas on Windows (unless one uses remote development). However, if one uses settings sync, the extension is installed on a Windows machine as well. Unless deactivated, a "do you want to install rr" modal shows up every time you launch vs code.

Confirmed on Linux too. Same problem.

This is a rather unfortunate situation where the installation process has left some business unfinished in the config file of midas. in ~/.config/Code/User/globalStorage/farrese.midas/.config. If you set midas_version to "0.0.0" this should go away.

Ok, I remove the extension and deleted ~/.config/Code/User/globalStorage/farrese.midas. Reinstalled (I did this without removing globalStorage/farrese.midas and didn't solved the problem) the extension and everything is now fine. I believe I installed the extension then rr which caused the unfinished business. On Arch Linux btw.


Implement getTransactionCount API/RPC call or potential nonce bugs

We're deploying the Edgeware lockdrop contracts on Edgeware (haha) and we need to use the contract's nonce to recover lock contract addresses. However, when we call this RPC on the contract after submitting TXs to it, it always returns 0. Is it properly implemented?

After recreating contract addresses with RLP encoding and creating 3 locks (1000, 10, 0.1 ETH) it seems they end up at the same lock contract (which shouldn't happen right since contract addresses are dependent on the initiator's nonce)
Lock contract: 42e2ee7ba8975c473157634ac2af4098190fc741 has balance<PHONE_NUMBER>000000000000.

@sorpaas any ideas why this might be the case? I was under the assumption that Ethereum contract addresses were generated using the nonce of the contract creator and incremented after each tx, but it seems the nonce is inherently remaining he same

I'm not sure what you are trying to do but I just tested creating the same contract 2 times, and the author nonce gets properly incremented, and the contract address is different each time. (using web3 sdk)
Contract deployed at address 0xC2Bf5F29a4384b1aB0C063e1c666f02121B6084a
Contract deployed at address 0x5c4242beB94dE30b922f57241f1D02f36e906915

So specifically, we're dealing with a contract that creates contracts. Therefore the contract should also have a nonce too, but the behaviour seems uncommon at best. Our contract code looks like the following
    function lock(Term term, bytes calldata edgewareAddr, bool isValidator) external payable didNotEnd {
        uint256 eth = msg.value;
        address owner = msg.sender;
        uint256 unlockTime = unlockTimeForTerm(term);
        // Create ETH lock contract
        Lock lockAddr = (new Lock).value(eth)(owner, unlockTime);
        // ensure lock contract has at least all the ETH, or fail
        assert(address(lockAddr).balance >= msg.value);
        emit Locked(owner, eth, lockAddr, term, edgewareAddr, isValidator, now);
    }

A new contract is created for the msg.value each time this function is called. However, when I run this with the master Frontier, and an rc5 substrate pallet-evm, I experience behaviour where the value is forwarded to the same contract each time the function lock is called rather than a new one each time the function is called.

Will get back with a smaller, tested contract for doing so. @jnaviasky is this something we have in the frontier-tester?

Closing this until it is more decisive, we have it working in https://github.com/hicommonwealth/frontier-tester


Exception when trying to get the user if the Users table has PK of int, and the user logged in with external provider

#780
@HaoK, I had to revert all my tables back to varchar because of a bug with int users.
Steps to reproduce:
Change the PK of user to int,
Login with external provider where the key isn't int compatible (FB, LinkedIn, etc.)
In the View use this:
UserManager.GetUserAsync(User);

Exception is thrown saying the key isn't int compatible.
Unfortunately we encountered it just before we had to demo something to our investors... so we change everything ASAP and didn't keep the exception and stack trace.

This is likely to be a dupe of https://github.com/aspnet/Identity/issues/860 where you need to turn off AutomaticAuthenticate for the external cookie, due to a bug in RC2 that's fixed in 1.0.0

@HaoK I'll give it a try in couple of days, after RTM and will let you know.

@HaoK So I moved to 1.0.0 and my PK is a string, and I'm not sure how I can go back to int because the table already has real data in it.
Any suggestions?

Can you try to migrate the data using EF Migrations?

@HaoK I hope I'll have the time for it in the weekend.
We are overwhelmed with tasks.
Will let you know soon.

@HaoK
Sorry for the extremely late response.
Our codebase has changed a lot since we moved  from int to string, it required a lot of time to get to that point in time and fiddle with that, and time is a thing crucially missing in an early stages startup.
As far as I can see, it's working now using RTM bits.
But I guess for us it's too late, as we have too much data which rely on varchar.
Well that's life.
Thanks.


T195077/docker compose for tests

Add ORES docker-compose file for testing purposes
This starts up 3 services (containers):

ores-api
ores-worker
redis

The tests seem to pass: make test
ores-api runs: ./utility applications.wsgi --config ./config/celery-test/
ores-worker runs: ./utility applications.celery --config ./config/celery-test/
And visiting the url http://localhost:8080/v2/scores/testwiki/revid/641962088?features=true does return results.
Considerations:

For simplicity, both the task queue and the score cache are pointed at the same redis. It can be split into 2 when needed.
I was skeptical about adding changes to test config files without breaking anything, so I added a new set of config files 'celery-test-docker'. It adds a 'docker_celery' to scoring_systems, a 'docker_redis' to score_caches and sets ores to use 'docker_celery' as its scoring system.
Celery seems to complain very hard when the service is run as root (which makes sense). I set the env var C_FORCE_ROOT to true to get it to start. Probably the best would be adding the user to application is supposed to be run by to the docker image.

This - plus all the stuff that I might have missed - should suffice to setup a dockerized dev environment.
Additionally, it should make the transition to kubernetes easier :)  (transitioning from docker-compose to kube is easy)

Bravo!  Verified working on my box, I'll merge since this definitely adds value.
I'm learning a lot, following all your progress :-)
The Travis CI docs don't make it clear how to run tests in a docker-compose environment, but I guess that's the next step, if you find more time for this project.  Thanks for all you've done here!


Omnisharp crashes for unknown reason

Environment data
dotnet --info output:
.NET Command Line Tools (2.1.4)

Product Information:
 Version:            2.1.4
 Commit SHA-1 hash:  5e8add2190

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.13
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.1.4/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

VS Code version:
Version 1.21.1 (1.21.1)
C# Extension version:
1.14.0
Expected  behavior
No crash and working Intellisense.
Actual behavior

Omnisharp crashes with this log:
Starting OmniSharp server at 2018-3-22 12:24:00
    Target: /path_to_project/project.sln

OmniSharp server started wth Mono
    Path: /Users/olle/.vscode/extensions/ms-vscode.csharp-1.14.0/.omnisharp/omnisharp/OmniSharp.exe
    PID: 37388

[info]: OmniSharp.Stdio.Host
        Starting OmniSharp on MacOS 10.13.2 (x64)
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Located 2 MSBuild instance(s)
            1: Mono 15.0 - "/Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin"
            2: StandAlone 15.0 - "/Users/olle/.vscode/extensions/ms-vscode.csharp-1.14.0/.omnisharp/omnisharp/msbuild/15.0/Bin"
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Resolved 'Microsoft.Build.Utilities.Core' to '/Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/Microsoft.Build.Utilities.Core.dll'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Resolved 'Microsoft.Build.Tasks.Core' to '/Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/Microsoft.Build.Tasks.Core.dll'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Resolved 'Microsoft.Build.Framework' to '/Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/Microsoft.Build.Framework.dll'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Resolved 'Microsoft.Build' to '/Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/Microsoft.Build.dll'
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Registered MSBuild instance: Mono 15.0 - "/Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin"
            CscToolPath = /Users/olle/.vscode/extensions/ms-vscode.csharp-1.14.0/.omnisharp/omnisharp/msbuild/15.0/Bin/Roslyn
            CscToolExe = csc.exe
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'Microsoft.CodeAnalysis.VisualBasic.Workspaces, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=******'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'Microsoft.CodeAnalysis.VisualBasic.Features, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=******'
[info]: OmniSharp.Cake.CakeProjectSystem
        Detecting Cake files in '/path_to_project'.
[info]: OmniSharp.Cake.CakeProjectSystem
        Could not find any Cake files
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Initializing in /path_to_project
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Auto package restore: False
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Update workspace context
[info]: OmniSharp.DotNet.DotNetProjectSystem
        Resolving projects references
[dbug]: OmniSharp.MSBuild.ProjectSystem
        MSBuild environment:
Mode: Standalone
RunningTests: False
RunningInVisualStudio: False
MSBuildToolsDirectory32: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin
MSBuildToolsDirectory64: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin
MSBuildSDKsPath: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/Sdks
CurrentMSBuildConfigurationFile: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/MSBuild.dll.config
CurrentMSBuildExePath: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin/MSBuild.dll
CurrentMSBuildToolsDirectory: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin
VisualStudioInstallRootDirectory:
MSBuildExtensionsPath: /Library/Frameworks/Mono.framework/Versions/5.8.0/lib/mono/msbuild/15.0/bin

[dbug]: OmniSharp.MSBuild.ProjectLoader
        'CscToolPath' set to '/Users/olle/.vscode/extensions/ms-vscode.csharp-1.14.0/.omnisharp/omnisharp/msbuild/15.0/Bin/Roslyn'
[dbug]: OmniSharp.MSBuild.ProjectLoader
        'CscToolExe' set to 'csc.exe'
[info]: OmniSharp.MSBuild.ProjectSystem
        Detecting projects in '/path_to_project/Seerefine.sln'.
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/path_to_project/project.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/path_to_project/project.Tests.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/path_to_project/Seerefine.Test.Common/Seerefine.Test.Common.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/path_to_project/Seerefine.Tests.Api/Seerefine.Tests.Api.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/path_to_project/Seerefine.Jobs.Tasks.Archive/Seerefine.Jobs.Tasks.Archive.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/path_to_project/Seerefine.Jobs.Tests/Seerefine.Jobs.Tests.csproj'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'System.Runtime.Loader, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=******'
[info]: OmniSharp.Script.ScriptProjectSystem
        Detecting CSX files in '/path_to_project'.
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /path_to_project/project.csproj
[info]: OmniSharp.Script.ScriptProjectSystem
        Could not find any CSX files
[info]: OmniSharp.Stdio.Host
        Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
[info]: OmniSharp.Stdio.Host
        Configuration finished.
[info]: OmniSharp.Stdio.Host
        Omnisharp server running using Stdio at location '/path_to_project' on host 37350.
[dbug]: OmniSharp.Stdio.Host
        ************ Request ************
{
  "Type": "request",
  "Seq": 1,
  "Command": "/projects"
}
[dbug]: OmniSharp.Stdio.Host
        ************ Request ************
{
  "Type": "request",
  "Seq": 2,
  "Command": "/projects"
}
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'Microsoft.Build.resources, Version=<IP_ADDRESS>, Culture=en-US, PublicKeyToken=******'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'Microsoft.Build.resources, Version=<IP_ADDRESS>, Culture=en, PublicKeyToken=******'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'Microsoft.Build.Tasks.Core.resources, Version=<IP_ADDRESS>, Culture=en-US, PublicKeyToken=******'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'Microsoft.Build.Tasks.Core.resources, Version=<IP_ADDRESS>, Culture=en, PublicKeyToken=******'
[info]: OmniSharp.MSBuild.ProjectManager
        Adding project '/path_to_project/project.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /path_to_project/project.Tests.csproj
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'NuGet.Commands, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=******'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'NuGet.Common, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=******'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'NuGet.Frameworks, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=******'
[dbug]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Attempting to resolve 'NuGet.ProjectModel, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=******'
[fail]: OmniSharp.MSBuild.ProjectLoader
        This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ../packages/xunit.runner.visualstudio.2.1.0/build/net20/xunit.runner.visualstudio.props.
[warn]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '/path_to_project/project.Tests.csproj'.
/path_to_project/project.Tests.csproj

[dbug]: OmniSharp.DotNet.DotNetProjectSystem
        GetProjectModel: /path_to_project/project.csproj

Any idea how I can go about fixing this? :)

Have you done a dotnet restore of your project?


fix: change the payload for the _change event

:tada: This PR is included in version 3.4.0-alpha.19 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.16 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.2 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0-alpha.6 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Pinpoint precise dependency differences that caused output difference between NASA and ESA

The solution for #7 will be to unify dependency management between NASA and ESA, but we still want to know precisely which dependency(ies) caused the difference in outputs so we have a proper understanding of what specifically would cause such an issue, whether it be some change in underlying floating-point handling/precision, or otherwise.

@jsignell, when you're ready to dig into this, let me know.

Thanks for the ping. I will probably not get to this until a week or two from now.

Thanks for the ping. I will probably not get to this until a week or two from now.

Cool. No rush.

There are three possible explanations as far as I can tell:

the resolved environments are different enough that the results end up being substantially different
the results are different, but not meaningfully so (they are similar within a certain tolerance threshold)
the inputs are getting passed in differently (meaning the libraries themselves might not differ, just the input mechanism)

To try to get a better sense of what is going on I created the initial environments using pip+docker for ESA and mamba for NASA.
The resolved environments appear fairly similar. The most interesting difference is the nvidia packages and Pillow but I haven't dug into whether or not those are being used.

Package
NASA - conda
ESA - pip+docker

Brotli
1.1.0
---

certifi
2024.6.2
2024.6.2

charset-normalizer
3.3.2
3.3.2

cloudpickle
3.0.0
3.0.0

Cython
3.0.10
---

GDAL
3.8.5
3.8.5

idna
3.7
3.7

Jinja2
3.1.4
3.1.4

markdown-it-py
3.0.0
3.0.0

MarkupSafe
2.1.5
2.1.5

mdurl
0.1.2
0.1.2

numpy
1.26.4
1.26.4

nvidia-ml-py
---
12.555.43

nvidia-ml-py3
---
7.352.0

Pillow
---
9.0.1

pip
24.0
22.0.2

psutil
5.9.8
5.9.8

Pygments
2.18.0
2.18.0

pynvml
11.4.1
---

PySocks
1.7.1
---

requests
2.32.3
2.32.3

rich
13.7.1
13.7.1

sardem
0.11.3
0.11.3

scalene
1.5.38
1.5.42

setuptools
70.0.0
59.6.0

typing_extensions
4.12.2
---

urllib3
2.2.1
2.2.2

wheel
0.43.0
0.37.1

Next I loaded the tifs in numpy and ran allclose. They are indeed substantially different:
import numpy as np
from osgeo import gdal

esa = np.array(gdal.Open('./output/esa/dem.tif').ReadAsArray())
nasa = np.array(gdal.Open('./output/dem.tif').ReadAsArray())

np.allclose(esa, nasa)  # False

I am still working on trying to pare down the run scripts to see if the inputs are getting passed in differently or something.


songs stop playing after toggling to different audio device

OS:  Win 10 1607  build 14393.1480
Issue Descriptions:  When switching audio sources multiple times via outside app the songs stop playing. I have and AHK script (autohotkey) that changes the default audio output source (I use this toggle between my receiver on optical-audio-out and my headphones plugged into 3.5mm jack). If I toggle between audio devices and am playing music in play.google in chrome, the audio continue to play no matter how many times i toggle. In desktop player the song pauses after the second audio device toggle.
Steps to Reproduce:

Launch desktop player.
Play a song.
Toggle audio device via MMSYS.CPL by selecting "set as default device"  (Song keeps playing.)
Toggle audio device back to original device via MMSYS.CPL. (Song stops playing)

Desired Behavior:
User should be able to toggle audio devices as many times as wanted via MMSYS (or other means) and song will keep playing until stopped by user.

This was fixed in Chromium 59 (if I recall correctly) so once we update Electron to 1.7.x+ it shouldn't be a problem anymore


Enable HTTPS for the whole site

Today we have Let's Encrypt, so we could easily solve the problems like #73 by simply using HTTPS for everything.
@rexim, what would you say? I think I can set it up.

Includes #73
I'm ok with that. Thanks!

Okay, I'll set it up and notify you.

Done. Read further story at https://github.com/codingteam/horta-hell/issues/397, https://github.com/codingteam/horta-hell/pull/398, https://github.com/codingteam/horta-foundation/issues/35.

I second this.


[TASK] Mark parsing-internal classes and methods as @internal

Code that uses this library is not expected to call internal parsing functionality. Communicate this with the corresponding @internal annotation.
This allows us to boldly refactor the parser code.
Part of #668

So if we don't want to expose this method moving forwards, we should mark it as deprecated. In which case, we want the logger inferface implementation before we can do so, don't we?

No, I don't think not having the logger should be a blocker for deprecating things.

The Parser::get/setCharset methods are part of the current interface (and not actually used internally). If we want to remove them (I'm not sure), we should mark them as deprecated.

I have now created #688 to deprecate them.

Updated and repushed.

This is still marked as 'Draft'.

This is still marked as 'Draft'.

Oops, thanks - not anymore! :wink:


Erro doing exercise M01 - JSON Files Creating VM for DNS test

Module: 01
Lab/Demo: Configure domain name servers settings in Azure
Task: 03
Step: 03
Description of issue
Error in file running the command "New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile azuredeploy.json -TemplateParameterFile azuredeploy.parameters.json"
Cannot submit the files because are not supported .JSON
Opening the files in VS Code gives an error in line 7 col 1 who is the start of the file
Repro steps:

Download both files from GitHub / Upload to console - PowerShell
$RGName = "ContosoResourceGroup"
New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile azuredeploy.json -TemplateParameterFile azuredeploy.parameters.json

copy & paste work better than saving the file Alters the format as a web page Giving the error


error: could not find font. Try using a full description

qwelyt@machine ~ % sflock
error: could not find font. Try using a full description.

I have no idea what to do with this message. What font? What description?
I'm using Arch Linux and installed the AUR package ( https://aur.archlinux.org/packages/sflock-git/ ).
It has worked previously. I'm guessing some update in core or extra did 'something' which broke sflock.
But the error message is not really useful and I have no idea how to resolve it.

Hi Filip,
The default font is dejavu, which had a non trivial package update (see
Arch Linux news). It could be that this is the cause of the issue. I will
check if it works on my pc. For the moment, you can always supply a manual
font using the -f flag.
Op wo 2 nov. 2016 10:29 schreef Filip Bellander<EMAIL_ADDRESS>
qwelyt@machine ~ % sflock
error: could not find font. Try using a full description.
I have no idea what to do with this message. What font? What description?
I'm using Arch Linux and installed the AUR package (
https://aur.archlinux.org/packages/sflock-git/ ).
It has worked previously. I'm guessing some update in core or extra did
'something' which broke sflock.
But the error message is not really useful and I have no idea how to
resolve it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/benruijl/sflock/issues/20, or mute the thread
https://github.com/notifications/unsubscribe-auth/AARGGTtbfCPlFOJEUOs2WBW6Chrf43nDks5q6FfrgaJpZM4KnBPG
.

I followed the instructions on https://www.archlinux.org/news/ttf-dejavu-237-will-require-forced-upgrade/ but the problem persists.
How exactly should you use the -f flag?
I've tried different ways
Given
qwelyt@machine ~ % fc-list | grep "Mono"
/usr/share/fonts/OTF/NimbusMonoPS-BoldItalic.otf: Nimbus Mono PS:style=Bold Italic
/usr/share/fonts/OTF/NimbusMonoPS-Italic.otf: Nimbus Mono PS:style=Italic
/usr/share/fonts/noto/NotoMono-Regular.ttf: Noto Mono:style=Regular
/usr/share/fonts/TTF/DroidSansMono.ttf: Droid Sans Mono:style=Regular
/usr/share/fonts/TTF/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book
/usr/share/fonts/OTF/NimbusMonoPS-Regular.otf: Nimbus Mono PS:style=Regular
/usr/share/fonts/OTF/NimbusMonoPS-Bold.otf: Nimbus Mono PS:style=Bold
/usr/share/fonts/TTF/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique
/usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/TTF/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique

What here is a 'full description'?
Examples on what I've tried
 % sflock -f DroidSansMono.ttf
 % sflock -f Droid Sans Mono
 % sflock -f 'Droid Sans Mono'
 % sflock -f xft:Droid Sans Mono
 % sflock -f 'xft:Droid Sans Mono'
 % sflock -f Noto
 % sflock -f NotoMono-Regular.ttf
 % sflock -f Noto Mono
 % sflock -f 'Noto Mono'

All of which result in error: could not find font. Try using a full description.

You have to use the X font description:
https://wiki.archlinux.org/index.php/X_Logical_Font_Description
For example:  sflock -f "-microsoft-webdings------------"
Op wo 2 nov. 2016 om 11:46 schreef Filip Bellander<EMAIL_ADDRESS>
:

I followed the instructions on
https://www.archlinux.org/news/ttf-dejavu-237-will-require-forced-upgrade/
but the problem persists.
How exactly should you use the -f flag?
I've tried different ways
Given
qwelyt@machine ~ % fc-list | grep "Mono"
/usr/share/fonts/OTF/NimbusMonoPS-BoldItalic.otf: Nimbus Mono PS:style=Bold Italic
/usr/share/fonts/OTF/NimbusMonoPS-Italic.otf: Nimbus Mono PS:style=Italic
/usr/share/fonts/noto/NotoMono-Regular.ttf: Noto Mono:style=Regular
/usr/share/fonts/TTF/DroidSansMono.ttf: Droid Sans Mono:style=Regular
/usr/share/fonts/TTF/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book
/usr/share/fonts/OTF/NimbusMonoPS-Regular.otf: Nimbus Mono PS:style=Regular
/usr/share/fonts/OTF/NimbusMonoPS-Bold.otf: Nimbus Mono PS:style=Bold
/usr/share/fonts/TTF/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique
/usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/TTF/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique
What here is a 'full description'?
Examples on what I've tried
% sflock -f DroidSansMono.ttf
% sflock -f Droid Sans Mono
% sflock -f 'Droid Sans Mono'
% sflock -f xft:Droid Sans Mono
% sflock -f 'xft:Droid Sans Mono'
% sflock -f Noto
% sflock -f NotoMono-Regular.ttf
% sflock -f Noto Mono
% sflock -f 'Noto Mono'
All of which result in error: could not find font. Try using a full
description.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/benruijl/sflock/issues/20#issuecomment-257830871, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARGGaCWNDprwgpiQbRKtM696Bd2P2Bdks5q6GoBgaJpZM4KnBPG
.

Thanks! Now it's working
qwelyt@machine ~ % sflock -f "-*-droid sans mono-*-*-*-*-*-*-*-*-*-*-*-*"

Couldn't get DejaVu Sans Mono to work, which might be why just running sflock fails.
If I do xlsfonts | grep "dejavu"(DejaVu, dejaVu, Dejavu, etc) I get nothing.

I don't even have ttf-dejavu installed, so I am really confused why this error message appears to me?

Also, why not just not use a font that might cause breakage?

Also, why not just not use a font that might cause breakage?

I quickly scrolled through the xlsfonts list on my system (ArchLinux) and couldn't find any generic font where you can assume that it is available on most systems. Might be mistaken though.
Do you have any suggestions?

I think X includes fonts for many years now (for example "fixed"). I also think that using XListFonts might give a much broader coverage too.

For people that visit this thread after me, do this in terminal:
xlsfonts | grep -E "^.{1,20}$"
[pick a font name]
sflock -f [font name]

What worked for me is eg. sflock -f lucidasans-8
Note that you don't need to use the long sflock -f ---fixed--* format from above..
I assume sflock throws this error on Debian because `xslfonts | grep dejavu' returns nothing


Can you provide your .fonts files? Or tell how to download your fonts?

Font name: Source Code Pro
Installation
On Arch : sudo pacman -S adobe-source-code-pro-fonts
On Ubuntu : Follow this link


Dev/compass dogfooding

@shuwen @dlasky corrected some styling gotchas, added small, normal, large settings (as per the 0.6.5 hotfix)

:+1: other than stripping those 2 comments, nothing major

lgtm :+1:


Support for custom Unpack method

introduce Unpacker interface for customized unpacking.
type Unpacker interface{
  Unpack(v interface{}) error
}

For dealing with 'rebranding', the Unpacker will only have to deal with types:

bool, int64, uint64, float64, string
[]interface{}
map[string]interface{}

Solved by PR #17


Deprecated docs for local state management

Intended outcome:
Docs should be applicable for the recent version-
Actual outcome:
Docs refer to and explain usage of deprecated apollo-link-state
How to reproduce the issue:
See https://www.apollographql.com/docs/angular/basics/local-state.html
Versions
Docs are deprecated on the website on March 4th 2019

I created MR #1140 to update the documentation. If you think I missed something, feedback is welcome.

@ceelian my pull request was accepted so I think you can close this issue.


DBZ-7797 Fail fast if surrogate key for incremental snapshot doesn't exist

Fixes https://issues.redhat.com/browse/DBZ-7797

Hi @joschi thanks for the PR. I have only one concern: snapshot context may remain in an inconsistent state because of  snapshotDataCollection and correlationId not cleared. Can you please check this scenario with an integration test?

@joschi Hi, would it be possible for you to provide the tests as recommend? Thanks

@joschi Applied, thanks! Apon further thinking if the exception is thrown the connector will fail so the state will be reset.


[BUGFIX] Remove targetObject usage in dummy app

Resolves #355.
Changes proposed:

Remove targetObject usage in dummy app

:clap:


Increase lentgh of test resource random prefix

Issue #, if available:
Description of changes:
Check all that applies:

[ ] Did a review by yourself.
[ ] Added proper tests to cover this PR. (If tests are not applicable, explain.)
[ ] Checked if this PR is a breaking (APIs have been changed) change.
[ ] Checked if this PR will not introduce cross-platform inconsistent behavior.
[ ] Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

[ ] Linux
[ ] Windows
[ ] Android
[ ] MacOS
[ ] IOS
[ ] Other Platforms

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This forces S3 to use Path Style addressing instead of virtual/dns style addressing, i.e. it causes a change in behavior in tests, can't merge this.


Change the signature of the getGroup in the ParameterHandler class

This implements what is discussed in #409

I removed myself from the review, feel free to add me back if this PR is ready.

This feature is no needed anymore and the code changed a lot during the years. Closing


Broken link in enterprise guidance

Under header Current status of SharePoint Framework , link General Available (GA) milestone sends to a 404
Probably it can be removed, as not vital, and the same is reported in the same article later

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f553eaa8-5792-3bdf-d9a8-dcbfc92e53ab
Version Independent ID: e16322c4-8793-4f20-bc6a-984b78c1b403
Content: SharePoint Framework (SPFx) enterprise guidance
Content Source: docs/spfx/enterprise-guidance.md
Service: unspecified
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

this is still broken after 5 months :)

Looks like this issue is already resolved in #3011. The link mentioned now points to the right target.


[Scum and Villainy] Muscle resprowess_bonus comes from???

The MUSCLE character in our game, when resisting is rolling what looks like twice as many dice as he should be.  We have managed to trace it to a attribute called resprowess_bonus but cannot figure out where that is coming from.
I can see it in the HTML, its an input, but we cant find it in his sheet, or figure out why it would have started as 'activated'.  Doesn't seem correspond to any of his abilities as far as we can tell.  But we've only played about 20 sessions at this point?
None of the other sheets seem to have this problem, just the Muscle playbook.  My mechanic for example is 3 Hack, 3 Rig, 2 study, but I still only roll 3 dice on that resistance roll.

I'm playing a pilot in this same game, and like @ShivonQ I also have no 'resbonus' attributes visible on my attributes and abilities tab, but I do see the same hidden attr_resbonus_* inputs in the html of my character sheet (all have zero as the value), and I see the same resbonus referenced in the template strings that are presumably used to calculate the number of dice to roll when clicking on insight, prowess, or resolve. However, for unknown reasons our MUSCLE character DOES have resbonus values listed on his attributes and abilities tab with a 3 for resbonus_prowess and a 1 for resbonus_insight.
I scoured the S&V rulebook and couldn't find a situation in which a character would have permanent bonus dice for a particular attribute, so unless it's something that roll20 requires on character sheets, I don't see the purpose of any of the resbonus attributes.

In the settings (little gear, top right), there are fields to add a permanent resistance bonus to characters. Set these to 0 to disable this. @ShivonQ Someone must have set these to some value at some point.

Closing this issue as it seems to be resolved. If there are outstanding problems, please consider creating a new issue.


create a new lab: nifty

nifty will be a low-code, metaprogrammable, standards sensitive and highly secure implementation to issue and trade NFTs, in a protocol agnostic way.
nifty code will address market place utilities for issuance and trading of NFTs.
Signed-off-by: Vipin Bharathan<EMAIL_ADDRESS>

@lehors @trbs please review. There is heavy interest across multiple SIGs and WGs about this lab.


SqlKata IncludeMany Problem

I have the below code snippnet
db.Query("dbo.SummaryCtor").
IncludeMany("Discrepant", q => q.From("dbo.OffDiscrepant").WhereColumns("SummaryCtor.OffloadingId", "=", "OffDiscrepant.ReceiptID"));
This results in Error as follows
Error	CS1061	'Query' does not contain a definition for 'IncludeMany' and no extension method 'IncludeMany'  accepting a first argument of type 'Query' could be found (are you missing a using directive or an assembly reference?)	QueryBuilder

Can anyone be of help

The Include function is not released yet in the stable version, to use it now use the nightly build instead.
check this for more details https://sqlkata.com/docs#nightly-builds


Combine operation (HLIL -> PseudoC) likely has bug

Version and Platform (required):

Binary Ninja Version: [e.g. 3.2.4000-dev] (if version is stable, please also test the latest development build via the "Update Channel" option)
OS: Windows
OS Version: 11
CPU Architecture: x64

Bug Description:

There appears to be a bug in how HLIL lifts 64 bit operations on 32 bit binaries. The expected behavior would be COMBINE(arg2, arg1) as seen in LLIL and HLIL, but instead the Pseudo C reports COMBINE(arg1, arg1).
Steps To Reproduce:
I was not able to create a binary that did this, but any binary that does div in assembly would expect to do the similar behavior on a 32 bit binary.

Fixed in builds >= 3932


add support for newrelic private minions

Chart for newrelic private minions - https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/private-locations/install-containerized-private-minions-cpms

hey @sstarcher
Have you considered hosting this chart and adding it to helm hub?
https://github.com/helm/hub/blob/master/Repositories.md

@maorfr I have no interest in hosting a chart repo.

its really just a github repo...
I think that you totally should host your own charts!
This will give you more freedom around management, and you will not be blocked by us (maintainers).
This means that when users want to install your chart, instead of installing them from stable, they will install it from (for example) mycompany-charts:
$ helm install --name my-release mycompany-charts/mychart
Here are some instructions about how to host your own charts repo:
https://github.com/helm/hub/blob/master/docs/github.md#github-pages-as-a-repository
In order for people to find out about your charts repo, you should add it to helm hub:
https://hub.helm.sh/
Here are some instructions about how to add your charts repo to helm hub:
https://github.com/helm/hub#how-to-add-your-helm-charts
wdyt?

@maorfr Ahh, I guess that approach can work I did not consider using github pages to host static content.  Will this approach continue to be the preferred approach in helm 3?  And is the overall goal to deprecate the helm/charts repo?

The primary concern about just hosting it in github pages is I lose all of  the testing support that is built into helm/charts so overall I don't think it's a preferred approach.

this is the preferred approach moving forward :)
to make things easier, we are working hard on creating better docs and tools to help users achieve that.
this is still the way though :)

@maorfr if the preferred approach moving forward is to use personal distributed repos(which makes sense) please close this ticket out.  Your last message was not 100% clear me me.

my last message is:
yes, this is the preferred approach :)
sorry for the confusion.
thanks for getting involved!
looking forward to see your helm hub PR!


Links with #place do not work

Links with #place do not work, it has a strange effect and stays where it is.
the same wiht "window.location.href"

Sorry, I just saw this — I'm not sure why I hadn't seen it earlier. Do you have an example repo I can take a look at?

Closing this issue because of inactivity.


Possible network latency issues: nipostBuilder Post service not connected - Post service not registered

Description

I have set up a SpaceMesh node on my Mac book and provided enough disk space and accepted the given Proof Generation. After Quick syncing, the network was up and running and in sync. I am now 4 hours further and it does seem it is smeshing but it is just not posted to the network. As the log shows multiple times this entry after each smeshing.

2024-03-03T11:22:56.047+0100	WARN	87edf.nipostBuilder	post service not connected - waiting for reconnection	{"node_id": "87edfcc91e8f1af90a64c727f39d63d891d14a8a1e4e198b6b47b4d8ee9ea665", "module": "nipostBuilder", "service id": "87edfcc91e8f1af90a64c727f39d63d891d14a8a1e4e198b6b47b4d8ee9ea665", "error": "post service not registered"}

Steps to reproduce

Go to '...'
Click on '....'
Scroll down to '....'

Actual Behavior

No SMH has been tallied in the mac osx application .
Reward address is not reported by the SpaceMesh explorer. It tells me it is non-existent.
In the reward section of the SpaceMesh explorer no rewards show up when filtering on the wallet address, nor the wallet id, nor the smesher id.
Wallet is also reported by the SpaceMesh explorer as non-existent in the account section.
Expected Behavior

SMH gets tallied in the mac osx application as smashing is recorded on the network.
Reward address is reported by SpaceMesh explorer as existent and active.
In the reward section of the SpaceMesh explorer rewards show up when filtering on the wallet address, or the wallet id, or the smesher id.
Wallet address is reported by SpaceMesh explorer as existent and active and receiving SMH.
SpaceMEsh node application reports Rewards being tallied.
Node logs show no errors that the post service is not connected. It shows that the post service is used to post smashing to the network and that it is successful.
Environment
Please complete the following information:

OS:

Mac OSX 12.7.3

Node Version:

v1.3.11+4f5cce199eb1fdde459307d9ff85ad54bf206ba3

Smapp version (if applicable):

1.3.12
Additional Resources

node-config.7c8cef2b.json
node-config.json
postdata_metadata.json
smeshing_metadata.json
spacemesh-log-7c8cef2b.txt

It looks like I am treading water here, nothing gets onto the network.

I am restarting smeshing now to see what happens. I am running an Intego Net barrier firewall that tells me it is allowing connections to and from go-spacemesh. I have not had any challenge from it to approve any connection.

At startup the log reports:

2024-03-03T08:09:01.525+0100	WARN	87edf.timesync	failed to read response from peer	{"node_id": "87edfcc91e8f1af90a64c727f39d63d891d14a8a1e4e198b6b47b4d8ee9ea665", "module": "timesync", "pid": "12D3KooWR2tr5Ki3m5GrVrvSvmSNqpsUWYJfEzwBdVvMneVeYxaQ", "errmsg": "read compact header: i/o deadline reached", "name": "timesync"}

Right before it gives the first instance of the above warn log entry after starting up.
I am guessing somebody knows what it means.

Another possible reason might be:

WARN	87edf.timesync	failed to create new stream	{"node_id": "87edfcc91e8f1af90a64c727f39d63d891d14a8a1e4e198b6b47b4d8ee9ea665", "module": "timesync", "pid": "12D3KooWEhSSzfpjYr88o4XTPkCSKVeCUC9uKqTgD98LXVYY8fL4", "errmsg": "failed to negotiate protocol: protocols not supported: [/peersync/1.0/]", "name": "timesync"}

A traceroute does indeed take 'forever':

➜  ~ traceroute <IP_ADDRESS>
traceroute to <IP_ADDRESS> (<IP_ADDRESS>), 64 hops max, 52 byte packets
1  <IP_ADDRESS> (<IP_ADDRESS>)  30.001 ms  2.025 ms  1.896 ms
2  * * *
3  zl-rc0001-cr102-et109-251.core.as33915.net (<IP_ADDRESS>)  12.958 ms  10.639 ms  11.345 ms
4  asd-tr0021-cr101-be151-2.core.as33915.net (<IP_ADDRESS>)  14.822 ms  14.390 ms  15.728 ms
5  * * *
6  d192002.upc-d.chello.nl (<IP_ADDRESS>)  14.503 ms  15.354 ms  11.698 ms
7  adm-bb1-link.ip.twelve99.net (<IP_ADDRESS>)  14.298 ms *
adm-bb2-link.ip.twelve99.net (<IP_ADDRESS>)  16.410 ms
8  ffm-bb1-link.ip.twelve99.net (<IP_ADDRESS>)  20.321 ms  22.036 ms
ffm-bb2-link.ip.twelve99.net (<IP_ADDRESS>)  22.036 ms
9  ffm-b5-link.ip.twelve99.net (<IP_ADDRESS>)  21.777 ms  20.621 ms  20.733 ms
10  chinamobile-ic-355891.ip.twelve99-cust.net (<IP_ADDRESS>)  23.347 ms  24.692 ms  20.008 ms
11  <IP_ADDRESS> (<IP_ADDRESS>)  30.949 ms  32.351 ms  38.270 ms
12  * <IP_ADDRESS> (<IP_ADDRESS>)  246.478 ms
<IP_ADDRESS> (<IP_ADDRESS>)  262.274 ms
13  * * <IP_ADDRESS> (<IP_ADDRESS>)  242.536 ms
14  * * *
15  <IP_ADDRESS> (<IP_ADDRESS>)  254.270 ms
<IP_ADDRESS> (<IP_ADDRESS>)  249.929 ms
<IP_ADDRESS> (<IP_ADDRESS>)  253.684 ms
16  <IP_ADDRESS> (<IP_ADDRESS>)  210.704 ms
<IP_ADDRESS> (<IP_ADDRESS>)  266.543 ms
<IP_ADDRESS> (<IP_ADDRESS>)  222.352 ms
17  * <IP_ADDRESS> (<IP_ADDRESS>)  205.626 ms *
18  <IP_ADDRESS> (<IP_ADDRESS>)  280.363 ms
<IP_ADDRESS> (<IP_ADDRESS>)  231.469 ms  220.167 ms
19  * * *
20  * * *
....

Giving it another try without the firewall running.

Reported the issue with SpaceMesh support under issue id 40e5ab51fca842e3b9cc95bfa05d099b

Not sure if this is checking the post service, but after some searching on the website I found this on Github:

curl http://localhost:50051/status
curl: (7) Failed to connect to localhost port 50051 after 0 ms: Couldn't connect to server

Well I guess I might have to wait till I get another newer mac book....

I am throwing in the towel. Now each time my Time Machine starts a backup my laptop becomes totally unresponsive. The SpaceMesh node is not for the people who can not afford modern laptops. 😉 Is this another crypto project that falls victim to its own success? Well too bad. I would have loved to contribute but if I want that now I either need to fork money for a newer laptop or get a monthly fee based vpn. We will see if I get back in the future. For now there is nothing left than to remove the node from my laptop.

Hey @etmjansen
there are few "issues" here.
First of all the "high latency" one. You took some high latency peer that you have been connected to and... well yes  have high latency. Nothing to worry about here. Normal situation with p2p. By it's high port I think it was UPnP based so... all ok.
Then local post service API
It's not yet in the release nor default to enable it so localhost:50051 is not used by anything. And remote IP peer obviously don't expose it too. Expected.
Why your post service is not connected that's likely other issue.

So basically it's all ok.
To get any SMH you need to wait at least one epoch (2 weeks) https://spacemesh.io/blog/requirements-for-spacemesh-rewards/

Now each time my Time Machine starts a backup my laptop becomes totally unresponsive.

You should not back up your PoST data directory. For performance I would even recommend to move the directory to a different disk than your OS, then backup and using your Macbook while the node is running should still be possible.

a newer laptop or get a monthly fee based vpn

Initialization is computationally difficult by design but only has to be done once. If your internal graphics card isn't powerful enough to do it in a reasonable time I would recommend to rent a vps for a few days, initialize there and then download the data to your macbook. After that the node can operate on less powerful Macbooks as well: 2019 Macbook Pro or newer work - never tested on older MacBooks but might still work depending on your PoST size (but you will have to init on a different machine).
The warning from your original post:

2024-03-03T11:22:56.047+0100 WARN 87edf.nipostBuilder post service not connected - waiting for reconnection {"node_id": "87edfcc91e8f1af90a64c727f39d63d891d14a8a1e4e198b6b47b4d8ee9ea665", "module": "nipostBuilder", "service id": "87edfcc91e8f1af90a64c727f39d63d891d14a8a1e4e198b6b47b4d8ee9ea665", "error": "post service not registered"}

Can safely be ignored in your case - your node hasn't finished initialization, which means it also hasn't started the internal post service yet. I can only extrapolate from the logs but on your machine the node will take at least 7 days to init, so I would recommend either upgrading to newer hardware or initialize your PoST in the cloud.

No SMH has been tallied in the mac osx application.

That seems to be a misunderstanding of how our protocol works. To be eligible for rewards you need to initialize PoST, then participate in PoET and then create another PoST. If you start fresh that means at least 2 weeks (and up to 4 depending on your timing) that your node needs to be online before you get your first rewards.

Since I don't see a real issue here I'm closing the ticket. @etmjansen if you need help setting up and running a node feel free to join our community on discord: https://discord.com/invite/yVhQ7rC (you can also find the link on https://spacemesh.io), where other users and members of the spacemesh team can help you do so 🙂


Examples segfault on Linux (most likely related to #by_ptr annotations)

Seems like examples are no longer compiling due to missing trailing commas all over the place.
For example:
sokol-odin/build > odin version
odin version dev-2023-01:c949e404

sokol-odin/build > odin run ../examples/clear -debug
/home/erik/Documents/GitHub/sokol-odin/examples/clear/main.odin(53:40) Syntax Error: Missing ',' before newline in compound literal

once I fix the trailing commas I get a segfault:
sokol-odin/build > odin build ../examples/clear -debug
sokol-odin/build > ./clear.bin
zsh: segmentation fault (core dumped)  ./clear.bin

Running on
OS:   Fedora Linux 37 (Workstation Edition), Linux 6.1.5-200.fc37.x86_64
CPU:  11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz

Ok, PR is merged, the segfaults are concerning though. Only reason I can think of is that it's an ABI issue where function parameters aren't correctly passed from Odin to the C side (e.g. by value vs by pointer).
I'll need to look into this after I finished up my current cleanup work on sokol_audio.

Do you happen to know where it crashes? e.g. which call caused it?

I can't repro on Windows with latest sokol & Odin.
Odin: dev-2023-01:c949e404
OS:   Windows 11 Home Basic (version: 21H2), build 22000.1455
@EriKWDev Did you remember to re-run build_clibs_linux.sh after updating sokol-odin?

Did you also check to see if it worked without the -debug flag? If it's -debug related, that's nice to know.

On M1 Mac I also cannot reproduce the segfault. I tested with brew-installed Odin, both --HEAD odin version dev-2023-01:c949e404 and regular odin version dev-2023-01:86511d44.
I'll check on my Ubuntu laptop next...

@EriKWDev Did you remember to re-run build_clibs_linux.sh after updating sokol-odin?

Right, that could actually be the reason which is easy to overlook. I wonder if I can somehow make this more obvious or even automate. One solution would be commit the prebuilt libs into the git repo, but I don't want to go there yet :)

@gingerBill I can reproduce the segfault in the produced executble on Linux with odin version dev-2023-01-nightly:86511d44 (haven't tested other versions yet), happens both with and without --debug (so it seems to be a Linux specific issue).
I'll see if I can find out more in a debugger...

Oh wow, something unrelated: I just randomly ran on my M1 Mac:
odin run ../examples/offscreen -debug

...and this crashed the compiler with:
 odin(77871,0x1f03b7a80) malloc: Heap corruption detected, free list is damaged at 0x600001793540
*** Incorrect guard value:<PHONE_NUMBER>0944
odin(77871,0x1f03b7a80) malloc: *** set a breakpoint in malloc_error_break to debug

...now that I try it repeatedly it happens fairly often (this is for version odin version dev-2023-01:86511d44 which I think is the 'stable' version installed via homebrew.
odin(78430,0x1f03b7a80) malloc: Heap corruption detected, free list is damaged at 0x6000000743f0
*** Incorrect guard value:<PHONE_NUMBER>0080
odin(78430,0x1f03b7a80) malloc: *** set a breakpoint in malloc_error_break to debug

odin(78359,0x1f03b7a80) malloc: Heap corruption detected, free list is damaged at 0x6000004b6550
*** Incorrect guard value:<PHONE_NUMBER>00160
odin(78359,0x1f03b7a80) malloc: *** set a breakpoint in malloc_error_break to debug

...ok, looks like I cannot reproduce this specific issue any longer in the --HEAD version (odin version dev-2023-01:c949e404)... back to that Linux topic :)

Ok, on the Linux crash. This is super weird. The crash seems to happen entirely on the C side and doesn't seem to be related to any parameter passing from the Odin to the C side.
The crash happens because this string copy function gets an invalid pointer for "src" (not a nullptr, just some random value):
https://github.com/floooh/sokol/blob/b3aecb21825f3191a9a150bc0918fc8c7df7855c/sokol_app.h#L2870-L2889
...when called from here:
https://github.com/floooh/sokol/blob/b3aecb21825f3191a9a150bc0918fc8c7df7855c/sokol_app.h#L2932
...but this html5_canvas_name is initialized here with a static string "canvas":
https://github.com/floooh/sokol/blob/b3aecb21825f3191a9a150bc0918fc8c7df7855c/sokol_app.h#L2904
...and that string pointer in the struct is valid, so it's the function argument that's corrupted somehow during the call.
I'll see if I can bisect the issue checking different Odin version.
Has something stack related changed in recent times maybe?

...deleted my last comment because it was entirely misleading :D
Ok, about that Linux crash...
The crash happens on the C side in a string copying function because it gets an invalid src pointer (its not a null pointer but some random value):
https://github.com/floooh/sokol/blob/b3aecb21825f3191a9a150bc0918fc8c7df7855c/sokol_app.h#L2870-L2889
...which is called from here, the corrupt pointer is _sapp.desc.window_title:
https://github.com/floooh/sokol/blob/b3aecb21825f3191a9a150bc0918fc8c7df7855c/sokol_app.h#L2947
...this window title string pointer is ultimately passed in here on the Odin side via a struct:
https://github.com/floooh/sokol-odin/blob/5fddee836fe3cb42afa2933a46310a71fa340420/examples/cube/main.odin#L135-L146
...hm ok... I think this is related to the struct being created inside the function call. If I change the main function like this:
main :: proc () {
    desc := sapp.Desc{
        ...
    };
    sapp.run(desc);
}

...then the sapp.run() call seems to work, but it's then crashing in another function where I'm using the same construct to build the struct inside a function call.
Happens only on Linux though!

The problem goes all the way back to when #by_ptr was introduced in dev-2022-07 (that's how far I went back checking older Odin versions for now... to go further back I need to remove the #by_ptr annotation.
I guess I didn't check carefully enough on all platform when that change happened in the bindings.
sapp.run() is one of those function which now use the #by_ptr annotation (previously there was a generated Odin wrapper function which took a struct value as input, took the address of the value and passed that on to the C function which expects a pointer).

...hmm no, it's now quite as simple as that. Even when changing one of the samples to move all the struct initializations out of the function call, there's still data corruption, it's just different places where this data corruption is caught (e.g. not resulting in a pointer access segfault, but an assert on the C side might trigger).

Going back to the generated Odin bindings from 15-Oct-2022 (this was one day before the #by_ptr annotation was introduced in the sokol-odin bindings) makes it work with the latest Odin compiler.
Instead of the #by_ptr annotations, the functions which expect a pointer on the C side, in that version, the external C versions were described like this:
sapp_run :: proc(desc: ^Desc)  ---

...and then there was an Odin wrapper function which took care of the value-to-pointer conversion which looked like this:
run :: proc(desc: Desc)  {
    _desc := desc
    sapp_run(&_desc)
}

Well this a bizarre bug indeed. I'm very surprised that it is failing this way but should be easy enough to fix now that I know what the problem is.

Oki doki, I think that's also all I can provide from my side for now. I'll go back to my regular sokol things then :)
Thanks for looking into this!

@thePHTest Yes, I rebuilt the c-libs. I also tried deleting the sokol-odin folder, re-cloned it and still got a segfault.
I compiled the odin compiler with debug enabled (./build_odin.sh debug) and then ran the 'clear' example with gdb.
After the segfault, I type bt full and got this:
Reading symbols from clear.bin...
(gdb) run

Starting program: /home/erik/Documents/GitHub/sokol-odin/build/clear.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000044b336 in _sapp_strcpy (src=0x12c00000190 <error: Cannot access memory at address 0x12c00000190>, dst=0x471ac8 <_sapp+3784> "", max_len=128) at c/sokol_app.h:2875
2875	        c = *src;

(gdb) bt full

#0  0x000000000044b336 in _sapp_strcpy (src=0x12c00000190 <error: Cannot access memory at address 0x12c00000190>, dst=0x471ac8 <_sapp+3784> "", max_len=128) at c/sokol_app.h:2875
        i = 0
        __PRETTY_FUNCTION__ = "_sapp_strcpy"
        end = 0x471b47 <_sapp+3911> ""
        c = 0 '\000'
#1  0x000000000044b7cb in _sapp_init_state (desc=0x7fffffffd810) at c/sokol_app.h:2947
        __PRETTY_FUNCTION__ = "_sapp_init_state"
#2  0x000000000044fe20 in _sapp_linux_run (desc=0x7fffffffd810) at c/sokol_app.h:11760
        pthread_attr = {__size = '\000' <repeats 17 times>, "\020", '\000' <repeats 37 times>, __align = 0}
        visual = 0x0
        depth = 0
#3  0x0000000000450090 in sapp_run (desc=0x7fffffffd810) at c/sokol_app.h:11856
        __PRETTY_FUNCTION__ = "sapp_run"
#4  0x000000000040d646 in main.main () at main.odin:46
        context = <optimized out>

@gingerBill I tried compiling without -debug the application still segfaults.
If there is anything further I can do to help debug this please let me know. I am quite new to Odin so I will try to compile an older version of the Odin compiler and see if I can get it to run with it

Thanks @EriKWDev These are the same problem I'm seeing. And it seems to related to the new #by_ptr bindings feature. I think there's not much more we can do at the moment (except going back to the older bindings style, but let's see if @gingerBill finds a fix first :)

Just wanted to let you know that this is still a problem with latest odin version and sokol-odin, but I am now getting a different error:
> odin version
odin version dev-2023-02:16262800
> odin run ../examples/clear
*** stack smashing detected ***: terminated

Probably just a different symptom of the same issue though.
with odin run ../examples/clear -debug and gdb:
clear.bin: c/sokol_gfx.h:15687: sg_setup: Assertion `(desc->_start_canary == 0) && (desc->_end_canary == 0)' failed.

Hmm ok, thanks for the update. I was just tinkering with the bindings yesterday again to integrate the new logging (but this was on macOS, where the problem doesn't exist).
If it doesn't look like the problem can be solved on the Odin side, it probably makes sense to go back to the old method which didn't use #by_ptr... I'll try to make some time experimenting with this over the next days.

I can take a look over the next few days to fix the ABI with #by_ptr on Linux.

Made some progress today and am discussing it in the #bugs_discussion channel on the Odin discord. I should have an update in another day or so.

@EriKWDev This should be fixed now if you use the latest Odin commit.

Can confirm that it now works for me with the latest Odin compiler commit:
> odin version
odin version dev-2023-02:233f47cc

Great work!!

Agreed, great work @thePHTest!


[Priority: Medium] Don't allow to delete a wallet file when node is running

(1) Is it possible? (2) Does it even matter?
(2) Does it even matter?
The wallet file is stored in memory, it will be serialized eventually, so even if the wallet file is deleted, it'll reappear properly.
(1) Is it possible?
It may not be possible on every OS, but even if it is, I'd stay far away from OS permission management magic. You'll just end up building more bug into.

I guess we could keep a lock on the file.
But point 2 makes sense so closing this.


Inner For-loop should not memoize.

Towards #1230

Current coverage is 96.10%

Merging #1233 into master will not affect coverage as of b005640

@@            master   #1233   diff @@
======================================
  Files           78      78
  Stmts         9168    9168
  Branches      1717    1717
  Methods          0       0
======================================
  Hit           8811    8811
  Partial         92      92
  Missed         265     265

Review entire Coverage Diff as of b005640

Powered by Codecov. Updated on successful CI builds.


WHL File of SHAP for amazon linux

Is there whl support for amazon linux .

Error: PythonPipBuilder:ResolveDependencies - {shap==0.30.1(wheel)}
This build error coming

Hi @AbhinavMudgal. Can you please re-test this on latest version of shap? There are wheels built that should work on most current Linux distributions.

@thatlittleboy Candidate for closing because of lack of response.
@AbhinavMudgal if the issue is still active for you, the issue can be reopened.


ml-development-tools tests fail due to initialization errors

Version of MarkLogic Java Client API
develop branch
Version of MarkLogic Server
On 9.0 and 10.0 nightly build
Java version
Oracle Java 9.0
OS and version
Happens on both Widows and Linux.
Input: Some code to illustrate the problem, preferably in a state that can be independently reproduced on our end
Run gradle command to generate tests for ml-development-tools project's tests.
./gradlew ml-development-tools:generateTests
Actual output: What did you observe? What errors did you see? Can you attach the logs? (Java logs, MarkLogic logs)
Exceptions are thrown.
Exception in thread "main" java.lang.ExceptionInInitializerError
	at com.marklogic.client.test.dbfunction.FntestconfKt.setupModules(fntestconf.kt:128)
	at com.marklogic.client.test.dbfunction.FntestconfKt.dbfTestSetup(fntestconf.kt:55)
	at com.marklogic.client.test.dbfunction.FntestconfKt.main(fntestconf.kt:48)
Caused by: java.lang.RuntimeException: 401 Unauthorized
	at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.makeClientImpl(DBFunctionTestUtil.java:65)
	at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.makeTestClientImpl(DBFunctionTestUtil.java:43)
	at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.makeTestClient(DBFunctionTestUtil.java:30)
	at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.<clinit>(DBFunctionTestUtil.java:16)
	... 3 more

> Task :ml-development-tools:setupTestServer FAILED

8016_AccessLog.txt produced this output:
<IP_ADDRESS> - - [03/Sep/2019:14:10:55 -0700] "GET / HTTP/1.1" 401 209 - "okhttp/3.10.0"
<IP_ADDRESS> - rest-reader [03/Sep/2019:14:10:55 -0700] "GET / HTTP/1.1" 401 209 - "okhttp/3.10.0"

Looks like RuntimeException from makeClientImpl(....) method during static initialization in
public final static DatabaseClient db = makeTestClient(); causes the JVM to throw java.lang.NoClassDefFoundError during test execution.
Expected output: What specifically did you expect to happen?
Tests generated.
Alternatives: What else have you tried, actual/expected?

The fix to #1121 switched from admin to rest-reader but neglected to create the rest-reader user.
So, it works if you previously setup the Java unit tests (which create the rest-reader user) but not if you setup the tools unit tests in isolation.
Modifying the setup should fix this issue.

Confirmed that this change creates the rest-reader user

Looks like we need to have a Http/Rest server running on port 8012 in-order for Data Services tests (at least static tests for time being) to be generated and run to completion successfully through gradle tasks.
Running ./gradlew ml-development-tools:generateTests produces
> Task :ml-development-tools:setupTestServer FAILED
Exception in thread "main" java.lang.ExceptionInInitializerError
        at com.marklogic.client.test.dbfunction.FntestconfKt.setupModules(fntestconf.kt:138)
        at com.marklogic.client.test.dbfunction.FntestconfKt.dbfTestSetup(fntestconf.kt:55)
        at com.marklogic.client.test.dbfunction.FntestconfKt.main(fntestconf.kt:48)
Caused by: java.lang.RuntimeException: java.net.ConnectException: Failed to connect to localhost/<IP_ADDRESS>:8012
        at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.makeClientImpl(DBFunctionTestUtil.java:68)
        at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.makeRestClientImpl(DBFunctionTestUtil.java:40)
        at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.makeRestClient(DBFunctionTestUtil.java:25)
        at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.<clinit>(DBFunctionTestUtil.java:19)
        ... 3 more
Caused by: java.net.ConnectException: Failed to connect to localhost/<IP_ADDRESS>:8012
        at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:242)
        at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:160)
        at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:257)
        at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135)
        at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:114)
        at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:126)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at com.burgstaller.okhttp.AuthenticationCacheInterceptor.intercept(AuthenticationCacheInterceptor.java:45)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
        at okhttp3.RealCall.execute(RealCall.java:77)
        at com.marklogic.client.test.dbfunction.DBFunctionTestUtil.makeClientImpl(DBFunctionTestUtil.java:62)

As a workaround, tried this workflow to run all of the tool's tests:
Note : testServerInit task was used so that we have a HTTP or RESTApp Server on poirt 8012.
./gradlew marklogic-client-api:testServerInit
./gradlew ml-development-tools:generateTests
These above steps produces another failure:
> Task :ml-development-tools:setupTestServer FAILED
Exception in thread "main" java.lang.RuntimeException: Could not create rest-reader user: 400
        at com.marklogic.client.test.dbfunction.FntestconfKt.createEntity(fntestconf.kt:116)
        at com.marklogic.client.test.dbfunction.FntestconfKt.setupServer(fntestconf.kt:83)
        at com.marklogic.client.test.dbfunction.FntestconfKt.dbfTestSetup(fntestconf.kt:54)
        at com.marklogic.client.test.dbfunction.FntestconfKt.main(fntestconf.kt:48)

The reason for above failure is clear.First and second task, both, creates rest-reader user.
Finally, had to use Admin GUI to create a Http Server on 8012. Then ran following two gradle tasks to have all static Data Services tests run successfully.
./gradlew ml-development-tools:generateTests
./gradlew ml-development-tools:test

I'm puzzled why the ConnectException is thrown.
On the develop branch, the setupModules() function at line 138 of fntestconf.kt doesn't connect to the server:
https://github.com/marklogic/java-client-api/blob/develop/ml-development-tools/src/test/kotlin/com/marklogic/client/test/dbfunction/fntestconf.kt#L138
Just to confirm, is the test is using the develop branch?

Yes. Tests are run on develop branch.

Tested with latest pull. Tests are generated and they ran as expected, without any failures.


add getSchemaResolved function

While getSchema function return the original schema added to the validator instance,
getSchemaResolved is to return a schema with reference resolved.
example:
{
        "id": "/refschema/r1",
        "definitions": {
            "url": {
                "type": "string",
                "format": "uri"
            }
        },
        "properties“: {
            ”repo": {
                "$ref": "#/definitions/url"
            }
        }
};

after resolve
{
        "id": "/refschema/r1",
        "definitions": {
            "url": {
                "type": "string",
                "format": "uri"
            }
        },
        "properties": {
            "repo": {
                "type": "string",
                "format": "uri"
            }
        }
};

@RackHD/corecommitters @cgx027 @iceiilin

+1

Still :+1: for me.

Thanks @yyscamper , added test case as your suggestion


Change default_cusomer_id to default_customer_id

This is a simple naming typo fix for clarity and documentation improvement.

@jgladfelter thanks!


Links within slide not working (even w/ preventClicks)

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Swiper Version: 5.3.8

Platform/Target and Browser Versions: macOS Chrome

What you did
var mySwiper = new Swiper ('.swiper-container', {
	slidesPerView: 'auto',
	spaceBetween: 40,
	loop: true,
	slidesOffsetBefore: 40,
	preventClicks: false,
	preventClicksPropagation: false,
	mousewheel: {
		forceToAxis: true,
		releaseOnEdges: true,
		sensitivity: 5,
		invert: true
	},
});

Expected Behavior
Links within slide to work.
Actual Behavior
Links to not work.  Each of my slides has an overlay that appears on hover of the slide.  This overlay includes a link.  The links aren't working.  I've tried adding the preventClicks: false as well as adding the class "swiper-no-swiping" to the links to no avail.  Any other ideas?
I've seen this issue in multiple threads, but none seem to offer a solution past adding "swiper-no-swiping" or "preventClicks: false".  For example, this thread was closed without a solution the only explanation being that the op was using an overlay - https://github.com/nolimits4web/swiper/issues/2638.  I can remove the overlay and just have the links within the slide and they still don't work so it's not an issue with overlay, css, etc.

Ignore.    I had pointer events off in my CSS.


Project crashes on play, producing vulkan errors, caused by settings in world environment. Project sometimes unrecoverable.

Godot version
v4.1.3.stable.official.f06b6836a
System information
Godot v4.1.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; <IP_ADDRESS>34) - Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (8 Threads)
Issue description
PLEASE NOTE: This issue seems to be fixed in Godot v4.2-rc1, however due to the potential to break projects, I (and others in the community) feel I should submit this report anyway, if not useful directly, then at the very least to have the issue tracked.

the project debug window will hang, while in the console these errors are spammed:

E 0:00:03:0309   swap_buffers: Vulkan: Cannot submit graphics queue. Error code: VK_ERROR_DEVICE_LOST
<C++ Error>    Condition "err" is true. Returning: ERR_CANT_CREATE
<C++ Source>   drivers/vulkan/vulkan_context.cpp:2360 @ swap_buffers()
E 0:00:03:0365   prepare_buffers: Vulkan: Did not create swapchain successfully. Error code: VK_NOT_READY
<C++ Error>    Condition "err != VK_SUCCESS" is true. Breaking.
<C++ Source>   drivers/vulkan/vulkan_context.cpp:2283 @ prepare_buffers()
Must hit stop, or close the window.

After further testing I found this much more serious problem with other specific settings:
same as above will happen, without the errors as it will also hang the editor - nothing drawn inside the window just the navy background.
After then closing the app and reopening the project, it sometimes will not run, just hangs.
This is sometimes recoverable by deleting the .godot folder, but not always.

Steps to reproduce
Create new 3D scene >> add WorldEnvironment and Camera3D nodes.
Set up the environment settings as in the image:
(Doubtful that the colors or specific settings are relevant)

Click the play button and you should see the first issue as above. Disabling fog allows it to run without errors.
The same project can test the second error: Simply disable glow while fog is enabled, click play and it should hang without errors, and hang the editor after closing the window, etc.
These errors only seem to happen if the background mode is set to clear color. I tested custom and sky >> procedural and did not experience these problems.
Minimal reproduction project
Environment_Bug_Test.zip

Thanks for the report! Consolidating in https://github.com/godotengine/godot/issues/71929, as this is due to the same cause.

After then closing the app and reopening the project, it sometimes will not run, just hangs.
This is sometimes recoverable by deleting the .godot folder, but not always.

If this hang is due to specific project settings, edit project.godot to remove the offending settings.
If this hang is due to specific editor settings, remove editor_settings-4.tres from the editor configuration folder while the editor is closed to reinitialize settings to their default values.

@Calinou Thank you, luckily I did not encounter the "unrecoverable" situation in any real project. Still, it's good to know that I can edit those settings if I encounter any similar issues.


Refactoring the visualizer parts

... to create a public ohmEditor API and have only one global.
@pdubroy: How do you feel about that?
@lilyx: I know that this changes some things for the semantics editor as well, but my main goal was to refactor the code so I will have an easier way to programmatically load semantics. Please let me know any concerns and I am happy to work this refactoring into the changes on the sv branch!

Hey Marko, this generally looks good. One thing I'd change is to only put stuff in ohmEditor that actually needs to be shared between modules. Some stuff (e.g. saveEditorState/restoreEditorState) should probably remain private to index.js. If we export everything, I'm not sure it provides much benefit over just using globals.
Also, when you merge, can you either squash the commits, or make sure that it's clear that they are all related to refactoring in the visualizer (e.g., by prepending viz: to them)? In the next Ohm release, I'm planning on producing a changelog, which means I'll have to scan through all the commits we've made in the past few months in order to provide a summary. That'll be easier if I can see at a glance what stuff is purely visualizer-related.
Anyways, LGTM if you trim the private stuff from ohmEditor.


[INTERNAL] Move test infrastructure from azure to github actions

Migrating test matrix execution from azure to github actions
Remove azure / azure coverage specific coding and dependencies
Update badge url in README.md
use node v20 instead of outdated 19

coverage: 94.589%. remained the same when pulling 0bd1a24bab4d34d4a31eed7687b1d2ef8ba8b68b on gh-migration into 41fa2d627e11db43ebd8aed2ed23922bc10dfaa2 on main.

As discussed, since we fixed the Azure pipeline with https://github.com/SAP/ui5-builder/pull/923 and https://github.com/SAP/ui5-builder/pull/921, we stick to Azure for the time being.


Pass network request arguments in an object

Summary
This changes the interfaces of network requests to accept arguments in an object as there are optional params that currently require being explicitly coded as undefined:
interface INetworkService {
  get<T>(args: {
    url: string;
    networkRequest?: NetworkRequest;
  }): Promise<NetworkResponse<T>>;

  post<T>(args: {
    url: string;
    data: object;
    networkRequest?: NetworkRequest;
  }): Promise<NetworkResponse<T>>;

  delete<T>(args: {
    url: string;
    data?: object;
    networkRequest?: NetworkRequest;
  }): Promise<NetworkResponse<T>>;
}

Changes

Change the INetworkService interface to accept arguments as objects and propagate in codebase
Update test accordingly

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

28 of 28 (100.0%)  changed or added relevant lines in 9 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.04%) to 93.276%

Files with Coverage Reduction
New Missed Lines
%

src/routes/transactions/entities/tests/human-description.builder.ts
4
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
6385

Relevant Lines:
6607

💛  - Coveralls

Some unintended changes were added to the PR after the main branch merge. Happy to review it again when it is ready!