The binary rules got violated

I found an example (https://github.com/sunfishcode/hello-wasi-http) that violates import/export name rules
importname' ::= 0x00 len:<u32> in:<importname>                       => in  (if len = |in|)
exportname' ::= 0x00 len:<u32> en:<exportname>                       => en  (if len = |en|)

The problem part is pointed out as below:
0x1a | 01 13 77 61 | [instance 0] ComponentImport { name: ComponentImportName("wasi:io/error@0.2.0"), ty: Instance(0) }

0x215de2 | 00 1c 69 6d | [type 0] ComponentImport { name: ComponentImportName("import-type-incoming-request"), ty: Type(SubResource) }

At 0x1a it uses old encoding, meanwhile, at 0x215de2 it uses the rule as document.

Tools version

cargo-component-component 0.18.0
wit-bindgen-rt = { version = "0.35.0", features = ["bitflags"] }

This is related to the binary format change in https://github.com/WebAssembly/component-model/pull/263. It appears something is still writing out old-style component import section entries that start with 0x01.

It appears cargo-component 0.18 is using an older version of wasm-encoder. I've now submitted https://github.com/bytecodealliance/cargo-component/pull/352 to fix this.


Sak 25438 - Download resources into a zip on the fly

Too many conflicts because I started this work in August... Better close this PR and redo the branch.


Fail to load (with Roaming Profile?)

So far my experiments have shown that I cannot load MarkPad under my corporate account but I can under my regular account. I suspect this has to do with my Roaming Profile and I'm happy to explorer further. Details as recorded in the Event Log are as follows:
Application: MarkPad.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: Autofac.Core.DependencyResolutionException
Stack:
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(System.String[])
at MarkPad.SingleInstanceManager.Main(System.String[])

Have you been able to replicate this? I know there was discussion in Jabbr, not sure whether there was progress made.

OK I have confirmed that this is the issue and I believe that it is unique to my environment. Here is the code that GetStore(..) is running (more or less):
var scope = IsolatedStorageScope.Assembly | IsolatedStorageScope.User | IsolatedStorageScope.Roaming;

var instance = (IsolatedStorageFile)Activator.CreateInstance(typeof(IsolatedStorageFile), true);
typeof(IsolatedStorage).GetMethod("InitStore", BindingFlags.NonPublic | BindingFlags.Instance, null, new[] { typeof(IsolatedStorageScope), typeof(Type), typeof(Type) }, null).Invoke(instance, new object[] { scope, null, null });

var RootDir = typeof(IsolatedStorageFile).GetMethod("GetRootDir", BindingFlags.Static | BindingFlags.NonPublic, null, new[] { typeof(IsolatedStorageScope) }, null).Invoke(null, new object[] { scope }).Dump("Root Dir");
var AssemName = typeof(IsolatedStorage).GetProperty("AssemName", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(instance, null).Dump("Assem Name");
var SeparatorExternal = typeof(IsolatedStorageFile).GetProperty("SeparatorExternal", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(instance, null).Dump("Separator External");

var path = String.Join("", new[] { RootDir, AssemName, SeparatorExternal }).Dump("Path");

try {
	Type.GetType("System.IO.LongPathDirectory").GetMethod("CreateDirectory", BindingFlags.Static | BindingFlags.NonPublic).Invoke(null, new object[] { path });
}
catch(TargetInvocationException tex)
{
	tex.InnerException.ToString().Dump();
}

This shows that the path it is trying to create exists under a UNC path \\myserver\userAccountm$\profile\Application Data\IsolatedStorage\ and it throws the following:
System.IO.IOException: The filename, directory name, or volume label syntax is incorrect.

   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.LongPathDirectory.InternalCreateDirectory(String fullPath, String path, Object dirSecurityObj)
   at System.IO.LongPathDirectory.CreateDirectory(String path)

This is not the first app that has run into this sort of issue with my roaming profile set up. We can potentially fix this by having a boolean setting to indicate whether Roaming profile is to be used or not because turning it off makes it work from my local drive. If that sounds OK I'll add it and send a pull request.


Unsafe function overload resolution when applied with generic arguments

TypeScript Version:  2.4.1
Code
Case 1
// overloaded functions
declare function f(a: number): number;
declare function f(a: string): string;

function g<T extends number | string>(a: T) {
    return f(a); // either of arguments is acceptable
//           ~
// Argument of type 'T' is not assignable to parameter of type 'string'.
//  Type 'string | number' is not assignable to type 'string'.
//    Type 'number' is not assignable to type 'string'.
}

Case 2
declare function f2<T>(a: Promise<T>): number;
declare function f2<T>(a: T): string;

function g2<T>(a: T) {
    const result: string = f2(a); // first overload is ignored, but the argument can be a Promise
    return result;
}

Expected behavior:
Case 1: compiles with no errors
Case 2: error that type string | number is not assignable to type string
Actual behavior:
Case 1: error
Argument of type 'T' is not assignable to parameter of type 'string'.
  Type 'string | number' is not assignable to type 'string'.
    Type 'number' is not assignable to type 'string'

Case 2: compiles without errors
Note
I remember here were some discussions about that, so that verifying all possible paths may result in N*M complexity (N overloads, M constituent types in unions). I could not find it.
The second case seems unsafe at all, because skips a possibly valid overload which may effect on return type. I expect that f2(a) would be of type number | string because either of these two overloads can play. It actually has the same result with a: any.

If you say a generic without any constraints, like <T> then anything can be assigned to it, therefore the first overload pattern is ignored and the second one is selected.  In the first example, to compare apples to apples you would be better to write:
declare function f(a: Promise<any>): number;
declare function f(a: any): string;

Why is first overload ignored? If T can accept anything, including Promise<X> that means, in run time, the first overload would be selected.
declare function f<T>(a: Promise<T>): number;
declare function f<T>(a: T): string;

const g = <T>(a: T) => f(a);

declare const p: Promise<number>;

f2(p); // first overload, number in compile-time, number in run-time
g(p); // second overload, string in compile-time, number in run-time

What is f2 and g doesn't have any overloads.  Your code isn't matching what you are trying to explain.

@kitsonk sorry, it was a typo. I've updated the sample code and added more explanation.

I remember here were some discussions about that, so that verifying all possible paths may result in N*M complexity (N overloads, M constituent types in unions). I could not find it.

Here you go! #1805.

I was talking to @ahejlsberg about something like this a few days ago. Maybe we can bring it up again.

@DanielRosenwasser that would be great. I've walked through referenced #1805, and it seemed to only cover mostly case 1, and completely missing case 2 where you cannot really control function application.
When case 1 is just unfortunate, case 2 is really a source of compile-time and run-time inconsistency.

Current real world example: the current typings for react mean that React.createElement() cannot take a ReactType = keyof JSX.IntrinsicElements | ComponentType or ComponentType<P = any> = StatelessComponent<P> | ComponentClass<P>, even though it can take keyof JSX.IntrinsicElements or StatelessComponent<P> or ComponentClass<P>. This is pretty confusing!

@tycho01 pointed that the issue was identified before in https://github.com/Microsoft/TypeScript/issues/12424#issuecomment-320511965 by @jcalz when discussing #6606

That is delaying overload resolution until generic parameters are bound, this is synthesizing a union of possible result types when overload resolution would otherwise fail, they don't seem that similar?

Oh, reread OP, maybe it's worth opening what I thought it was as a new issue?

Sorry for the spam: nope, it's just #1805

@simonbuchan my point for claiming they're related is that they have the same overlooked case where run-time behavior that expressed by overloads is not reflected in the type system respectfully. However I agree that it may be worth to distinguish due to different implementation paths.

The generics at the repro in 12424 were unnecessary:
interface Match {
  (o: object): 0;
  (o: any): 1;
}
type Wrap = <T>(v: T) => Match(T);
type A = Wrap(RegExp);
// falls thru to 1, `object` checked not with generic val `RegExp` but with its constraint (generic `any`)

(I'm using #17961 though that wasn't needed)
If I comment A it no longer evaluates the overloads, so at least it doesn't do it that early.
It appears the Wrap evaluation is done inside of the A evaluation's resolveCallExpression though, which does in fact have access to that RegExp. Now to figure out how to propagate that such that it won't just default to the implicit any constraint on T in the checker's  checkApplicableSignature...

For me the problem is the way Wrap type-checks. There is an obvious information loss there. I see two solutions:

either allow the type parameter T to stay unconstrained as is now, but resolve the call to Match as a union of all possible returns
or, somehow propagate the overload to the caller. This means that Wrap itself should become an overloaded function.

The first option is not very useful for type level programming. The second option seems hard to implement and not in line with the current design.

@gcnew:

This means that Wrap itself should become an overloaded function.

Hm. The way I looked at it Match(T) shouldn't actually be resolved until the T is known, just like we van do T[K] and have it resolve when it knows what's what.
I imagine overload propagation could grow fast, and may better match the current design as well.
I mean, resolveCallExpression knows its argument types; I think that should be sufficient to resolve the type parameters' types before having to calculate the return type.
I hope that means applying that type parameter info for the purpose of calculating the return type, by e.g. pre-filling them to use those rather than just the constraints, should do the trick.
I may not seeing the full picture though, so any insights from those who do should help a lot.

Hm. The way I looked at it Match(T) shouldn't actually be resolved until the T is known

I think delaying the resolution is basically the same as propagating the overload. In both cases you'd have to compute the constraints to guarantee safety. In the propagation case you'd have the "overload" type at the top level, while in the other, you'd have to follow several indirections. I'm fine with either, as long as "all possible outcomes" (i.e. constraints) are properly computed and checked.
Note: the lazy approach would need bounds on the type variable as is the case with T[K].

I think delaying the resolution is basically the same as propagating the overload.

Oh, my interpretation had been that propagating the overload would mean storing the different possible outcomes, which may sound manageable in this toy example, but perhaps less so if we'd be nesting calls with respectively n, i, j overloads, making for n * i * j potential overloads throughout the evaluation from the top level.
I'm thinking we might not necessarily need much more complexity.
Knowing:

we just passed RegExp to v
inferring from this that T would be RegExp as well

... then if rather than <T>(v: T) => Match(T) we'd be evaluating <T>(v: T extends RegExp) => Match(T) instead, I'm thinking that might already evaluate to Match(RegExp) -> 0.


length() returns wrong number when using expression to filter an array

json path<EMAIL_ADDRESS>< 10)].length() returns 4
expected result should be 2
example json:
[
    {
        "author": "Nigel Rees",
        "category": "reference",
        "price": 8.95,
        "title": "Sayings of the Century"
    },
    {
        "author": "Evelyn Waugh",
        "category": "fiction",
        "price": 12.99,
        "title": "Sword of Honour"
    },
    {
        "author": "Herman Melville",
        "category": "fiction",
        "isbn": "0-553-21311-3",
        "price": 8.99,
        "title": "Moby Dick"
    },
    {
        "author": "J. R. R. Tolkien",
        "category": "fiction",
        "isbn": "0-395-19395-8",
        "price": 22.99,
        "title": "The Lord of the Rings"
    }
]

json path<EMAIL_ADDRESS>< 10)] returns:
[
   {
      "author" : "Nigel Rees",
      "category" : "reference",
      "price" : 8.95,
      "title" : "Sayings of the Century"
   },
   {
      "author" : "Herman Melville",
      "category" : "fiction",
      "isbn" : "0-553-21311-3",
      "price" : 8.99,
      "title" : "Moby Dick"
   }
]

Seems similar to #562

Seems similar to #562

Seems similar to #562

thanks for replying. i will use 2 steps to get the filtered length number temporarily

Seems similar to #562

thanks for replying. i will use 2 steps to get the filtered length number temporarily


Upgrading the template to Ghost 1.0

Using the https://gscan.ghost.org/ interface, fixed all the rules that were broken.

@PLMir thanks for the PR! Could you please test the theme in this version and confirm that it works correctly?

Hi! I have tested the team in this version and it works mostly. Things that are not working are the following: the publication cover (website banner) and featured images for post do not get displayed (they get displayed when reverting to the default theme) - although pictures within posts do get displayed; and the little "author bio" information at the end of each post is also not getting displayed. I'll look into it to see if I can fix it, or maybe you have pointers?

Thanks! I have no pointers unfortunately as I haven't been following Ghost's development. Might be worth checking the console for errors. Otherwise.. the template dev docs.

Hi again!
I have gone through the changes I made again, and finally understood what was wrong: actually nothing, the theme works juste fine! I was working the assumption that your personal website was a demo of the theme, and thought I had broken something since they didn't look alike. In short: this theme works.

Awesome news, thanks for the contribution!


Declaratively configure LXC containers

Issue description
It would be great to be able to declaratively configure LXC containers, like NixOS or docker containers.
Right now it has to be done manually.
  virtualisation.lxc = {
    enable = true;
    lxcfs.enable = true;
    defaultConfig = "lxc.include = ${pkgs.lxcfs}/share/lxc/config/common.conf.d/00-lxcfs.conf";
  };
  virtualisation.lxd.enable = true;

[root@nixos:~]# lxd init
[root@nixos:~]# nix-env -f https://github.com/nix-community/nixos-generators/archive/master.tar.gz -i
[root@nixos:~]# export CONF=/root/nixos-config/machines/minimal-container/configuration.nix
[root@nixos:~]# lxc image import $(nixos-generate -f lxc-metadata -c $CONF) $(nixos-generate -f lxc -c $CONF) --alias minimal
[root@nixos:~]# lxc launch minimal minimal-1

cc maintainer @fpletz

@davidak what's the advantage over systemd-nspawn? I assume it's much more popular these days…

@flokli it works. (maybe the last comment fixes nixos-containers https://github.com/NixOS/nixpkgs/issues/67970)
It also support other distros than NixOS.
And in general, i think, when we support a technology, like LXC, it should be fully configurable declaratively. That's what NixOS is about, right?

systemd-nspawn supports running not only NixOS containers, and is available on other distros than NixOS too.
I just proposed this, as it's probably used more widely these days for running full systems in separate namespaces. Declarative LXC configuration is still a valid ask, I'm just not sure how many are still using it.

Still important

Eh, it would be very good to have this :(

This would still be nice to have, so not stale.
It would also be nice to be able to configure LXD itself declaratively, instead of having to explicitly run lxd --init.  @c0deaddict has an example module that does this in https://discourse.nixos.org/t/example-config-for-nixos-as-host-for-lxd-lxc-containers/14322/2?u=cdepillabout.

LXD preseed PR now up. #253283

how about hooking up into lxd-pressed service?  systemd.services.lxd-preseed
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/lxd.nix#L229
It seems that this service is called on start (not restart / reboot though):
journalctl -u lxd-preseed

So possible a dedicated systemd.service main run after that service as well:
systemd.services."init-containers" = {
  wantedBy = [ "multi-user.target" ];
  requires = [
    "lxd.service"
  ];
  after = [
    "lxd-preseed.service"
  ];
  partOf = [
    "lxd-preseed.service"
  ];

  script = ''
    # prolly need to check if container is already created...
    /run/current-system/sw/bin/lxc launch images:ubuntu/22.04 test-ubuntu --profile=test1
  '';

  serviceConfig = {
    Type = "oneshot";
  };
};

This does spawn the expected container:

Going further:

a dedicated profile can be created for each containers to minimize imperative configurations
https://discourse.nixos.org/t/howto-setup-lxd-on-nixos-with-nixos-guest-using-unmanaged-bridge-network-interface/21591#setting-up-lxd-2 (thanks @cdepillabout)
container configuration can be stored into a .yaml and refer to that file when lxc launch / lxc init
https://documentation.ubuntu.com/lxd/en/latest/howto/instances_create/#pass-a-configuration-file


install: better win, linux install experience

eliminate platform warning when npm, yarn, etc
attempt to install on non darwin systems. this is
achieved by always installing, but artificially throwing
"Cannot find module 'fsevents'" when require()d
by dependents running on non darwin platform.
npm scripts entries also updated to bypass node-pre-gyp, etc.
when running on non darwin platform.

@es128 Just curious whats left to do to get PR merged and published?

I haven't had much time yet to evaluate and try it out. Nothing left on your side atm, pending any further feedback.

The install process LGTM.
The one concern I've noticed is that win/linux users will now have the fsevents dependency tree included in their node_modules. I am sure someone will end up complaining about this, but it does seem like the lesser evil.


read_csv: delim_whitespace ignored when skip_footer is set

The delim_whitespace options no longer works when specifying a skip_footer other then zero. I can replicate the behavior in 0.12 with the following example:
import pandas as pd
from StringIO import StringIO

indata = StringIO("""1.2   5.6   8.5
4.5   6.7   6.4

""")

indata.seek(0)
df = pd.read_csv(indata, delim_whitespace=True, header=None, skip_footer=2)

Which returns:
                 0
0  1.2   5.6   8.5
1  4.5   6.7   6.4

Note how its only one column, instead of three. Changing the skip_footer to 0 makes it work as expected.
indata.seek(0)
df = pd.read_csv(indata, delim_whitespace=True, header=None, skip_footer=0)

Returns:
     0    1    2
0  1.2  5.6  8.5
1  4.5  6.7  6.4
2  NaN  NaN  NaN
3  NaN  NaN  NaN

If the above example is used with something like names=['a','b','c'] an (obvious) 'ValueError' exception occurs: Expected 3 fields in line 1, saw 1.

@jreback : this isn't an issue anymore.  You can most certainly specify both together now.
>>> from pandas import read_csv
>>> from pandas.comat import StringIO
>>> data = """1.2   5.6   8.5
4.5   6.7   6.4

"""
>>> read_csv(StringIO(data), delim_whitespace=True, header=None, skip_footer=2,
skip_blank_lines=False, engine='python')   # skip_footer not supported in C engine
     0    1    2
0  1.2  5.6  8.5
1  4.5  6.7  6.4

Indeed. Note that the last comment from @jtratner about it failing was due to skip_blank_lines=True by default because of which the skipfooter was not needed anymore


Update the createTable and addField methods.

So currently both, methods, overwrites the InternalProps and ready them, thus effectively wasting 50ms, and losing old data which is critical.
Here is the new draft:

The createTable should just return if table exist in InternalProps and emit a process.warning.
For addField same, as create table but this time, throw a error.

And update the readme accordingly.

Other interesting thing is though makes sense is, adding a table takes about 14-20ms on average. But overwriting it takes around 50ms because it remove the old stuff and re-adds it.

Fixed in master...


XML documentation missing from NuGet package

When I add the NuGet package "DokanNet" to my project, there is no documentation for anything, and there are no XML documentation files anywhere in the package directory.
I managed to find a workaround to get XML documentation working.
I downloaded the DokanNet project, turned on generation of XML documentation (This was not enabled by default), then built the project.  Then I found the 230KB XML file named "DokanNet.xml" that it generated.
Then I went into the project's "Packages" directory, then everywhere I saw a file named "DokanNet.dll", I copy-pasted in the "DokanNet.xml" file.  After doing this, I got XML documentation in Visual Studio.

@Dwedit Hi,
Thank you for the feedback!
Would you like to make a contribution with the change you described to allow other users to also see the documentation?

Sorry, I don't know how to make the Nuget package generator place the XML files in the correct places, I'll need some more research for that, looking at it right now.
Right now I'm just doing it manually.

Fixed by https://github.com/dokan-dev/dokan-dotnet/pull/276 Thanks again @Dwedit for reporting the issue and providing the fix too 🏆 !!!


Fix dict type caster compilation with const &

The dictionary caster that I wrote has a compilation issue when the std::map is passed into the C++ caster as a const &. This change fixes it. I would also note that the same issue should probably be fixed in #84 as the conversion logic was modified from the dictionary caster.
nanobind/include/nanobind/stl/detail/nb_dict.h:57:43: error: type 'const std::map<std::__cxx11::basic_string<char>, std::vector<unsigned long, std::allocator<unsigned long>>, std::less<std::__cxx11::basic_string<char>>, std::allocator<std::pair<const std::__cxx11::basic_string<char>, std::vector<unsigned long, std::allocator<unsigned long>>>>> &' cannot be used prior to '::' because it has no members
                    forward_like<typename T::key_type>(item.first), policy, cleanup));
                                          ^

Ah wait, sorry -- I forgot that #84 is not merged yet. No need to do anything about that commit then.

Sure thing, I'm working on a test and I'm also investigating a potential segfault so I'll keep you posted.

That looks good. Shall I merge this, or are you still investigating the segfault? What was that, out of curiosity?

I've investigated the segfault. At first it seemed that it could have something to do with the map/dict conversion logic, but I think that the logic is correct. The culprit ended up being the default conversion of a very complex union type (that was incidentally stored within a map).

Thanks!


Check Guidelines Update

Please check if the PR https://github.com/zalando/restful-api-guidelines/pull/368 introduces changes which are relevant to the Zally project.

No Zally changes required. Safe to close.


Add initial annotation to the pod when starting

What this PR does / why we need it:
The benefit of doing this is that the pod will
respond to status requests more quickly and
if we try and patch the status (being careful
to not overwrite plugin results) we don't have
to worry about it not yet existing on the pod.
Which issue(s) this PR fixes
Fixes #696
Special notes for your reviewer:
Release note:
Fixed an issue where the aggregator may fail to annotate the pod as complete if no plugins are run.

Codecov Report

Merging #724 into master will decrease coverage by 0.08%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #724      +/-   ##
==========================================
- Coverage   40.09%   40.01%   -0.09%
==========================================
  Files          69       69
  Lines        3886     3894       +8
==========================================
  Hits         1558     1558
- Misses       2227     2235       +8
  Partials      101      101

Impacted Files
Coverage Δ

pkg/discovery/discovery.go
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Support spaces in file url

I tried verifying an ipa file that contains a space in its filepath:
var certDl = new (require('cert-downloader'));
  certDl.verify('storage/Ipa Help.ipa', function(error, output) {
    if(error){
      return callback(error);
    }
    callback(null, plist.parse(output));
  });

This fails because the filepath string is directly added to the openssl command without escaping.
changing the command line from
openssl smime -in %s -inform der -verify -CAfile %s'

to
openssl smime -in "%s" -inform der -verify -CAfile %s'

would prevent this.
What do you think about my issue?

Whoops... totally forgot to build a new release for that issue; this was fixed on master 5 months ago.
Sorry about that, I will double-check the code and wrap the fix into a new version asap. Thank you for your report!

Just published version 0.2.1, this should address your issue.

Thank you, works fine :)


Crashes if there are lots of objects in a document

This is an awesome plugin and something I was looking forward to for a long time! However, I cannot fix the problem that Sketch crashes with when there are lots of objects on a page / document, even if I try to remove everything unnecessary.
Any ideas what the problem could be? I have read about several other plugins that they also crash if there are too many objects.
I know that you listed it under "Known Issues" but maybe there is a way to fix it.

Thanks! We know this limitation is annoying. We agree, it must be some kind of memory issue in Sketch’s plugin interface that is related to the number of objects on the current page.
The workaround we currently use is splitting the document into multiple pages (like 1 or 2 artboards per page).
If you want to help, you may want to report this bug to the Sketch team.

This could help: https://github.com/preciousforever/sketch-toggle-layer-visibility/issues/2#issuecomment-71492382

Looks good. Thanks.

Is this still an issue? Then please let me know and I’ll reopen the issue.


Amazon auth failed both not working on v0.1.5 and v0.2.0.

 So what could be cool is if you allow the user to add its own extension to the amazon platform.
those are the modifications I've done!


is using task::spawn_blocking for cpu bound tasks adviced?

The documentation says it will be given its own thread from a special threadpool, and that it's designed for long running blocking code. Is there any reason why we can't use this for CPU heavy tasks or is there something that might make this a bad idea?

Yes, if you have a CPU-bound task, or any sort of task where polling its future may take a long time, that's the case spawn_blocking is intended to solve.
However, there's a bit of uncertainty around this. The async-std blog had an article talking about how you can just use spawn for everything, and the runtime will dynamically detect if it blocks for a long time, and let it have that thread for its exclusive use. But I'm told that that strategy may be on hold.


feat(zero-cache): fix paths to enable running under windows

closed in favor of https://github.com/rocicorp/mono/pull/3453


Finalize homepage views with data and filters

User Stories

As a user, I want to be able to see my posts on the homepage

I expect to see dates, URLs, and plural words properly formatted

In this lesson, I built on the Flask app I created earlier, and I introduced my SQLAlchemy models into the routes and templates. Some things required a bit more manual setup and teardown than what I'm used to in JavaScript, but the data ended up being used the same way.
In this lesson, I accomplished the following:
Queried a database using SQLAlchemy methods.
Managed database connections using the Flask app context.
Imported custom filters into a Jinja template.


The queue is growing as big as the memory!

I have created a producer and several comsumer threads.
Producer add work to the threads using thread_add_work function.
Consumers threadpool threads do their job.
Problem is:
if number of thread is 5 and producer is 100 times faster than the consumer, then queue size is just increasing.

I am not sure if this should be solved from the thread pool side. It is possible but it would make everything too complex for no good reason imo:

the user would need to specify max jobs when creating a thread pool, which defeats the aim to keep things simple and easy
if this is implemented with add_work blocking, it makes it counter-intuitive. Many (new) users would find it odd that this function just "hangs" there some times.
if this is implemented with the return of an error code QUEUE_FULL then the user would need to loop until the queue is not full. The problem with this is that it adds no benefit since the user can already do that without the added complexity to the thread pool. (And that brings to my suggested solution below.)

I think a simpler solution is to simply check how much work there already is in the queue before adding new tasks.
Pseudocode:
thpool = thpool_init(4)
..
while (thpool.jobqueue.len <10) {
    sleep(1)
}
thpool.add_work(a)

While assisting someone online with the same issue, I noticed that thpool is an opaque pointer, so the suggested solution is no longer viable.
the library should provide a function that return the job queue length

Just for posterity, here is a reproducing example:
int main(int argc, char *argv[]){
        threadpool thpool = thpool_init(4);
        printf("%d\n", thpool->jobqueue_p.len );
        return 0;
}

Probable solution: http://stackoverflow.com/questions/38714429/out-of-memory-in-a-thread-pool-in-c-linux


TF 2.17.0-rc0 compilation fails due to flag: `-mavx512fp16’; did you mean ‘-mavx512bf16’?

Issue type
Build/Install
Have you reproduced the bug with TensorFlow Nightly?
Yes
Source
source
TensorFlow version
2.17.0-rc0
Custom code
No
OS platform and distribution
Linux Ubuntu 22.04
Mobile device
No response
Python version
3.10
Bazel version
6.5
GCC/compiler version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
CUDA/cuDNN version
12.3
GPU model and memory
Quadro RTX 6000
Current behavior?

Target //tensorflow/tools/pip_package:wheel failed to build

Standalone code to reproduce the issue
See above.

Relevant log output
See above

@learning-to-play

@belitskiy @rtg0795 FYI

Building Tensorflow with GCC is not supported as of 2.13. Please use Clang instead:
See https://www.tensorflow.org/install/source

I have managed to use GCC up to 2.16.1. anyway, the reason is the version of clang required is newer than what Ubuntu 22.04 provides. With no support for GCC and clang too old, there is no way to compile TF 2.17.0 with Ubuntu 22.04....On Jun 25, 2024 3:18 PM, belitskiy @.***> wrote:
Building Tensorflow with GCC is not supported as of 2.13. Please use Clang instead:
See https://www.tensorflow.org/install/source
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

The guide linked above contains instructions on how to install Clang 17. This works for
Alternatively, use a Docker container from  https://hub.docker.com/r/tensorflow/build/tags. It comes with Clang pre-installed.

FWIW, this also pops up when building the MediaPipe Python wheel via python3 setup.py bdist_wheel. I have Clang 18 installed, but XNNPACK is choosing to use GCC anyway. It's unclear to me how to plumb this configuration through the multiple layers of build systems involved.


Alluxio worker K8S storage management

*Is your feature request related to a problem? Please describe.
Alluxio manages the worker storage according to the user-given storage space (e.g. alluxio.worker.tieredstore.level0.dirs.quota).
However in K8S, sometimes the storage space is shared by multiple applications.
K8S may not know the available storage space for Alluxio beforehand so configure a wrong storage size (large than actual).
Or during runtime, the storage space may be used out by other applications. When Alluxio thinks there are 10GB left but there may be only 1GB or none left.
Describe the solution you'd like
Alluxio has disk space detection.
Say when Alluxio is configured to have 30GB storage and Alluxio used 10GB. Other applications used 10GB.
Alluxio will know that it has 10GB left and will not fully use out the whole storage space which the whole pod (Alluxio) may be killed by K8S.
Describe alternatives you've considered
Users do disk space management outside Alluxio with K8S ways.
It's more complicated that way.
Urgency
Important, is a blocking issue
Additional context
Add any other context or screenshots about the feature request here.

@apc999 @beinan FYI

Does this mean that we need to check the available space from time to time at runtime？ Is it possible to use a small and safe quota (say <10GB ) as a workaround?

thanks @LuQQiu  for tracking our issues. 🌹
@beinan
Disk management is not a major problem on bare metal machine or dedicated servers. However, when it comes to k8s, everything changes.
We deploy alluxio with fluid(an alluxio controller responsible for deployment) on k8s shared with multiple applications.  Claiming 10GB is not a good idea because it may be scheduled on a machine with only 1GB disk left.
Our preliminary idea is that alluxio claims the disk usage, k8s-scheduler schedules alluxio workers based on the claim. Then alluxio has to make sure it can't exceed the usage.
Any other ideas are welcome. If there is any roadmap on this issue, pls let us know.

@ssz1997 FYI

@LuQQiu Is it possible to reserve 30GB?

According to @beinan it's hard for us to know how much storage actually left. We can reserve any number based on Alluxio configuration, but not based on actual storage space

Yes, as @LuQQiu mentioned, the quota could not be working based on the actual storage space unless k8s could provide this information.  But even though we know the actual storage when the alluxio starts, other application running on the same machine might still preempt the space during the alluxio running.   I don't have a workaround for this issue so far.
I'm thinking if we could reserve the space during the server start in the future, it sounds like a reasonable feature request to me.

Thanks for your kindly reply. It sounds that it's k8s responsibility for disk management.

Thanks for your kindly reply. It sounds that it's k8s responsibility for disk management.

Yeah, I'm not an expert of k8s, not sure if the disk management has already been there or not.

Close because Alluxio cannot know how many disk spaces left


Support apispec>=1.0.0b5

Fixes compatibility with apispec 1.x
close #1

Codecov Report

Merging #3 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master     #3   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           2      2
  Lines          20     20
=====================================
  Hits           20     20

Impacted Files
Coverage Δ

starlette_apispec/schemas.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Hi sloria, thanks for the PR.
Please make the PR to the branch dev which is already working on this. I'll merge it soon to master, and I'll make a pre-release to pypi
Cheers!

Will do!


Doxgyen workaround for getting namespace methods to show up

Certain namespace methods such as serac::buildMeshFromFile don't show up in the doxygen search. Apparently the namespace itself needs to be "documented" for doxygen to show the doxygen comments for namespace methods. stackoverflow

https://serac.readthedocs.io/en/feature-jonwong12-doxygen_workaround/
turned on your branch so you can see it

Codecov Report

Merging #320 (1892bc0) into develop (a51858f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #320   +/-   ##
========================================
  Coverage    90.72%   90.72%
========================================
  Files           43       43
  Lines         1649     1649
========================================
  Hits          1496     1496
  Misses         153      153

Impacted Files
Coverage Δ

src/serac/numerics/mesh_utils.hpp
100.00% <ø> (ø)

Continue to review full report at Codecov.

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

We do autobuild the doxygen with the sphinx on read the docs. The appropriate version is available here.

We do autobuild the doxygen with the sphinx on read the docs. The appropriate version is available here.

@jonwong12 do you think this is ready to merge?

@jonwong12 do you think this is ready to merge?

@jamiebramwell Yes.

@jamiebramwell Yes.

LGTM

LGTM


ARROW-8191: [Packaging][APT] Fix cmake removal in Debian GNU/Linux Stretch

Because cmake in stretch-backports requires newer libarchive13 but
newer libarchive13 only exists in stretch-backports-sloppy.

@github-actions crossbow submit debian-stretch

@github-actions crossbow submit debian-stretch

@github-actions crossbow submit debian-stretch

@github-actions crossbow submit debian-stretch

+1


Fix generated light probes placing too close to manual light probes

This is extracted from a conversation here: https://github.com/godotengine/godot/pull/83420.
While poking around in lightmap_gi, I noticed there is code to avoid generating probes too close to manually placed probes, but it was doing an is_equal_approx check against the two positions instead of a distance check, so this was never being triggered. I changed it to a distance check so the behavior is as expected now:

Thanks! And congrats for your first merged Godot contribution :tada:

Cherry-picked for 4.3.1.


Character movement stats class

Having this would allow character upgrades as these are used to manage movement upgrades (major and minor) and talk to the motion graph

Added MovementUpgradeSystem component to character prefab. Can modify various movement related properties (eg enabling jetpacks or modifying move speed) in there. Data modifiers (eg move speed) also use persistent rogue-lite data. Can tweak move speed from hub scene example and see effect in game.


Fixed the ballon spelling and also the bug that when cursor is fast i…

Corrected it @swapnilsparsh

@Bharadwajshivam28 Spelling isn't fix yet, and bug also

let me check it


Addition of Carousel at the landing page

We can add a beautiful carousel which tells the purpose of the website /story of the website /available books...etc.

@Mukesh751 go for it

Thank You Sir

@Mukesh751 any update ?

Sir, I will show you by tomorrow.


Remove go get go-bindata from generate.go

This mades the build impossible offline (as when doing a go generate it was trying to go get something)
Probably needs some documentation updates too (like do a go get …).. But I found it kinda bad to not be able to build traefik while offline, in the train :sweat_smile:.
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

OK for me, but README should indeed be updated ;)

@emilevauge ok, updating the README :cat:

LGTM, but needs a rebase :)

Rebased :wink:


Add doc comments to GeneratedMessage

This reduces the number of undocumented, public methods of GeneratedMessage from 21 to 13.
I also changed the style of all of the existing doc comments from the /** */ style to the /// style.

Merged.


Missing /kythe/edge/param for /kythe/edge/ref/call function

This is a follow up from: https://groups.google.com/forum/#!topic/kythe/I2vpv8L9oV0
I'm using Kythe 0.28
The instructions to produce the triples file which is missing the /kythe/edge/param should be:
git clone https://github.com/bfergerson/otherproject
cd otherproject

export REAL_JAVAC="$(which javac)"
export JAVAC_EXTRACTOR_JAR=/opt/kythe/extractors/javac_extractor.jar
export KYTHE_ROOT_DIRECTORY="$PWD"
export KYTHE_OUTPUT_DIRECTORY="/tmp/kythe"
export KYTHE_CORPUS=otherproject
mkdir -p "$KYTHE_OUTPUT_DIRECTORY"

mvn clean compile \
  -Dmaven.compiler.forceJavacCompilerUse=true \
  -Dmaven.compiler.fork=true \
  -Dmaven.compiler.executable=/opt/kythe/extractors/javac-wrapper.sh

cd ..

java -Xbootclasspath/p:/opt/kythe/indexers/java_indexer.jar com.google.devtools.kythe.analyzers.java.JavaIndexer /tmp/kythe/#3ff8f033c31a2273ebfbbccc40b02b9187b7c87f3f2a690f7bf5821d6451319e.kindex | /opt/kythe/tools/dedup_stream | /opt/kythe/tools/triples >> /tmp/kythe/triples_results.txt

Which should result in:
2018/08/11 18:01:02 dedup_stream: skipped 8 records
2018/08/11 18:01:02 Skipped 0 reverse edges
2018/08/11 18:01:02 Wrote 529 triples

But while trying to reproduce the issue outside of my application I'm running into another issue. The above actually creates an empty triples_results.txt file. Not sure what's happening here as the resulting .kindex file is only 232 bytes as compared to 6.6kB when I run it in my application.
Considering this isn't the issue I brought up I'll step over this for now and use the .kindex that my application produces using: https://github.com/CodeBrig/GitDetective/blob/ccb25e69875a74bfd1a61a602aecf1c33c8086d0/indexer/src/main/groovy/io/gitdetective/indexer/support/KytheMavenBuilder.groovy#L59. I believe this is the correct .kindex file anyway.
Now that the .kindex has been built and the triples_results.txt has been created you can search for: 5d3c119e684b5d35f9c2ccd0145b2dfc18ee25c83bafc92e212af6203459f0e1.
You won't find any /kythe/edge/param facts associated to that signature. This would seem to indicate that the function has no arguments but you can see it does here: https://github.com/BFergerson/otherproject/blob/b0be5053300ef5baabe7706f1cb440e38aa55565/src/main/java/com/gitdetective/App2.java#L26
So now I have two questions:

Why does the above script produce empty triples_results.txt?
Shouldn't there be /kythe/edge/param for 5d3c119e684b5d35f9c2ccd0145b2dfc18ee25c83bafc92e212af6203459f0e1 in the resulting triples_results.txt file?

First of all.  I'm very sorry for taking so long to get back to you.  We've had some technical difficulties as of late...

For the first issue, this appears in /tmp/javac-extractor.err:
SEVERE: compiler error: Source option 1.5 is no longer supported. Use 1.6 or later.
Errors encountered during compilation

Your KytheMavenBuilder handles this by adding -Dmaven.compiler.source=1.8 -Dmaven.compiler.target=1.8 to the build: https://github.com/CodeBrig/GitDetective/blob/ccb25e69875a74bfd1a61a602aecf1c33c8086d0/indexer/src/main/groovy/io/gitdetective/indexer/support/KytheMavenBuilder.groovy#L76.  You can do the same for the raw invocation and the .kindex file will be correctly extracted.

For the second case, param edges will only be emitted when visiting the function's definition.  Since App2.java only references myMethod2, only the function node will be emitted for the /kythe/edge/ref edge.

I believe all of this is working as intended so I'm going to close this issue.  Please reopen if you disagree or find another issue.


[REEF-632] Add container to the set of containers on restart such that YarnContainerManager will know how to release it

This addressed the issue by

Adding onContainersRecovered to YarnContainerManager and calling it on recovering containers in YarnDriverRuntimeRestartManager.

JIRA:
REEF-632

@markusweimer Fixed, please have another pass. Thanks!

Looks good, I will merge.


Updating the documentation

How can I update the docs? I wanted to fix a couple of typos but I couldn't follow the process/workflow to actually update the docs. If you could provide a quick walkthrough or even add it to the docs under a 'Contributing' heading then I as well as others will be happy to update them when/where we can.

They come with the source: https://github.com/tailwindcss/tailwindcss/tree/master/docs/source/docs

Hey @mstnorris! We published some instructions on building the docs locally this morning:
https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md#building-the-documentation


fix(react-native): move bbs dep to bbs package

Fixes #1065

Codecov Report

Merging #1076 (3d950a4) into main (f777b3d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1076   +/-   ##
=======================================
  Coverage   88.22%   88.22%
=======================================
  Files         679      679
  Lines       15901    15901
  Branches     2571     2571
=======================================
  Hits        14028    14028
  Misses       1865     1865
  Partials        8        8

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Only resizes the dock where tree-view exists

Hi, thanks for creating this package :)
I found the resizes via minimumWidth/maximumWidth can affect both right/left docks, and this can be annoying, and this PR fixes this.

@lexcast
could you tell me whether you can merge this and publish the new version ?
If not, I'm okay and going to publish my fork 😊

okay, I just published my fork: https://atom.io/packages/tree-view-autoadjust
and thus gonna close this PR 👋


[5.0] Added contextual binding on methods test

Contextual binding does not work on methods, only constructor functions.
I've added a (currently failing) test that checks that this works. (At least, I think that's what it's testing, I don't fully understand the Container class, so apologies if the test is wrong/stupid.)

Hmm, I don't think I ever intended it to really work on methods, although it is an interesting use case.

I've come across a situation where I feel like it would be the cleanest way to handle things: http://stackoverflow.com/questions/30477611/laravel-5-0-application-structure
Perhaps there's a better way of handling that specific scenario, but I still feel like it could be useful. If it was an easy change then it would be great to have.

Going to close this as it was never really an intended use case.

@taylorotwell Common use case would be now with laravel 5.1 where are self handling jobs.
Now you can't pass interfaces into job _constructor methods, as you cold with commandhandlers, because you pass input params directly into jobs, and now you need to pass interfaces into job's handle method. If i use interfaces with multiple implementations and pass it into job's handle method it wont be resolved.
This Example wont work, because there is no Contextual binding for methods:
<?php

use App\Jobs\Job;
use Illuminate\Contracts\Bus\SelfHandling;

class StripeSampleJob extends Job implements SelfHandling
{
    public $inputParam1;

    public $inputParam2

    public function __construct($inputParam1, $inputParam2)
    {
        $this->inputParam1 = $inputParam1
        $this->inputParam2 = $inputParam2
    }

    public function handle(PaymentInterface $paymentInterface)
    {
        return $this->paymentInterface->doSomething($this->inputParam1, $inputParam2)
    }
}

$this->app->when(StripeSampleJob::class)
          ->needs(PaymentInterface::class)
          ->give(StripeInterface::class);

 $this->app->when(PaypalSampleJob::class)
          ->needs(PaymentInterface::class)
          ->give(PaypalInterface::class);

@taylorotwell I agree with @ddctd143 that as self-handling jobs are now pushed as the norm it should be possible to do contextual dependency injection into the handle method. The current setup is strange because one type of binding works while another doesn't. It's not expected behavior as a user. The same sentiment can be found here https://github.com/laravel/framework/issues/6177

Yes I can definitely see a use case there. How hard is it to get the contextual binding to work at a method level?

@taylorotwell My understanding of the internals of Illuminate/Container isn't good enough to give you a straight answer on that. However, I can outline two types of behavior, the first being what might be the expected behavior now and the second probably being more complex to implement but a feature for the future.
1 .Class based method contextual binding: i.e, A class is bound to a particular concrete implementation and methods on that class are all given the same injection if they ask for it.
$app->when(MyClass::class)->needs(MyServiceInterface::class)->give(MyService:class);
MyClass@method(MyServiceInterface $myService) gets MyService injected.
This is more or less as we understand the current binding system. To enable this I assume the Container needs to be modified so that it checks the contextual binding map for a method's parent class when it resolves the dependencies for that method.

Class@method based method contextual binding: i.e, A Class@method is bound to a particular concrete implementation and that specific method is given that dependency when it asks for it.

$app->when(MyClass::class . '@someMethod')->needs(MyServiceInterface::class)->give(MyService:class);
This would allow another method on a particular class to have the same dependency hinted but get a different implementation. More of an edge use case than the first but not beyond the realms of imagination.

I may be a little out of my league here but would it make since to provide something like withContext on the container that would just push the class onto the build stack?
Container.php
    public function withContext($context, $callback)
    {
        $this->buildStack[] = $context;
        $value = $this->call($callback);
        array_pop($this->buildStack);

        return $value;
    }

Then anywhere that should support contextual method binding could wrap their calls.
examples
Container.php
    protected function getMethodDependencies($callback, array $parameters = [])
    {
        $dependencies = [];
        $reflector = $this->getCallReflector($callback);

        $this->withContext($reflector->class, function () use ($reflector) {
            foreach ($reflector->getParameters() as $parameter) {
                $this->addDependencyForCallParameter($parameter, $parameters, $dependencies);
            }
        })

        return array_merge($dependencies, $parameters);
    }

RouteDependencyResolverTrait.php
    protected function resolveClassMethodDependencies(array $parameters, $instance, $method)
    {
        if (! method_exists($instance, $method)) {
            return $parameters;
        }

        return $this->container
            ->withContext(get_class($instance), function () use ($instance, $method) {
                $this->resolveMethodDependencies(
                    $parameters, new ReflectionMethod($instance, $method)
                )
            });
    }

Not working on 5.1.46

This feature could be useful for contextual binding in the handle method of jobs.

Contextual binding per method initialization can make an implementation explicit and cognitively clear. I had the intention to fraction my requests implementation into few contracts, each per action type: UpdateRequestContract, SearchRequestContract, SomeGenericActionRequestContract then inject implementation per controller method, expl.:  DiscountController@search(SearchRequestContract) -> give(DiscountSearchRequest::class) ...
I'm not going to kibble ideas and bring dirt into the projects by inserting strange methods and workarounds. That will not make your co-workers feel excited about new features, instead, they rather will get a feeling of a new rib growing under the arm. The current implementation is already great and made my life better so I will keep working using it properly and wait for the new exited extensions.


Mobs (villagers and cows) disappears and reappears in my world.

Hi i have some issues with the additive modpack. My cows for example will go over walk trough the  fences visially but when i punch them they teleport back to the "farm". My villagers also keeps disappearing and reappearing in my iron farm.
I have seen the problems multible times and can get a screenshot of them if needed.
Best regards Erik

This might be a problem with entity tracking, try setting use_optimized_entity_tracking=true in config/vmp.properties

Sorry im not very good with that sort of stuff, how do i do that?

In your launcher (I assume you are using Prism or MultiMC), select your instance:

Click "Folder" on the right side:

Open .minecraft, then open the config folder, and then edit the vmp.properties file as shown in HyperSoop's message.

Thank you soo much, both of you. Hope you both have a great day.


Loop Overwritten in Server.Serve

A loop passed to sanic.server.serve will be overwritten if runasync=True:
https://github.com/channelcat/sanic/blob/599834b0e1c41d934dce30b6393926635f72b78e/sanic/server.py#L543
The behavior for this should be:
if not run_async and not loop:
    # create new event_loop after fork
    ...

In general, a loop cannot survive a fork or be shared across processes in any way. When multiple processes are being used, each process should create its own eventloop, which also implies that any objects which depend on the loop (such as aiohttp.ClientSession) must also be created in the child processes. We probably should not allow user pass in loop there.

Ah, makes sense.
I'm looking into handling HTTP redirects, which is related to #1250
The solution /may/ be to pass a custom loop to serve, but I only peeked into the rabbit hole.
Do you have any suggestions for #1250?
I'm going to close this, as it's not an issue.


Fix updating event

Data was not being copied to the form data, so it couldn't be altered!

Can we merge this?


Update gopkg reference to v3 (closes #72)

Coverage: 99.452%. Remained the same when pulling ba06d1a41a2c858a137ae37cc1968efbe1c0d9a1 on fix-readme into d38fb82ab6ed29b21e7e3f13345f52afb6e805fb on master.


RHEL: java-spring-boot2: appsody test fails

Describe the bug
Running BATS integration test which does an appsody stack validate against the stacks and I noticed the appsody test part of the validate is failing for both templates...
**************************************************************************
Running appsody test against stack:dev.local/java-spring-boot2 template:kotlin
**************************************************************************
[/usr/bin/appsody -v test --no-watcher]
[Debug] Logging to file /home/tnixa/.appsody/logs/appsody2019-12-11T14-05-26.639074071.log
[Debug] Project config file set to: /tmp/appsody-build-simple-test755797221/.appsody-config.yaml
[Debug] Project stack from config file: dev.local/java-spring-boot2:0.3
[Debug] Image repository set to: docker.io
[Debug] Project stack after override:  is: docker.io/dev.local/java-spring-boot2:0.3
[Debug] Running with command line args: appsody -v test --no-watcher
[Info] Running test environment
[Debug] Project config file set to: /tmp/appsody-build-simple-test755797221/.appsody-config.yaml
[Debug] Project stack from config file: dev.local/java-spring-boot2:0.3
[Debug] Image repository set to: docker.io
[Debug] Project stack after override: docker.io is: docker.io/dev.local/java-spring-boot2:0.3
[Debug] Stack image: docker.io/dev.local/java-spring-boot2:0.3
[Debug] Project directory: /tmp/appsody-build-simple-test755797221
[Debug] docker.io/dev.local/java-spring-boot2:0.3 image pulled status: false
[Debug] Pull policy IfNotPresent, checking for local image
[Debug] Docker image ls command output: 0c765d8319b3
[Info] Using local cache for image docker.io/dev.local/java-spring-boot2:0.3
[Debug] docker.io/dev.local/java-spring-boot2:0.3 image pulled status: true
[Debug] Image has been pulled already: docker.io/dev.local/java-spring-boot2:0.3
[Debug] Number of environment variables in stack image: 23
[Debug] All environment variables in stack image: [PATH=/opt/ibm/java/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin JAVA_VERSION=1.8.0_sr6 JAVA_HOME=/opt/ibm/java/jre IBM_JAVA_OPTIONS=-XX:+UseContainerSupport MAVEN_HOME=/usr/share/maven MAVEN_CONFIG=/root/.m2 APPSODY_USER_RUN_AS_LOCAL=true APPSODY_PROJECT_DIR=/project APPSODY_MOUNTS=.:/project/user-app;~/.m2/repository:/mvn/repository APPSODY_DEPS= APPSODY_WATCH_DIR=/project/user-app/src APPSODY_WATCH_IGNORE_DIR= APPSODY_WATCH_REGEX=(^.*\.java$)|(^.*\.properties$)|(^.*\.yaml$)|(^.*\.html$)|(^.*\.sql$)|(^.*\.js$)|(^.*\.properties$) APPSODY_RUN=/project/java-spring-boot2-build.sh run APPSODY_RUN_ON_CHANGE=/project/java-spring-boot2-build.sh recompile APPSODY_RUN_KILL=false APPSODY_DEBUG=/project/java-spring-boot2-build.sh debug APPSODY_DEBUG_ON_CHANGE=/project/java-spring-boot2-build.sh recompile APPSODY_DEBUG_KILL=false APPSODY_TEST=/project/java-spring-boot2-build.sh test APPSODY_TEST_ON_CHANGE= APPSODY_TEST_KILL=true PORT=8080]
[Debug] Environment variable found: APPSODY_MOUNTS Value: .:/project/user-app;~/.m2/repository:/mvn/repository
[Debug] Checking for existence of local file or directory to mount: /tmp/appsody-build-simple-test755797221/.
[Debug] Checking for existence of local file or directory to mount: /home/tnixa/.m2/repository
[Debug] Mapped mount args: [-v /tmp/appsody-build-simple-test755797221/.:/project/user-app -v /home/tnixa/.m2/repository:/mvn/repository]
[Debug] Environment variable found cached: APPSODY_DEPS Value:
[Debug] About to run docker with args [volume ls --format {{.Name}} -f name=appsody-controller-0.3.2]
[Debug] Retrieved volume name(s): [appsody-controller-0.3.2]
[Debug] Adding controller to volume mounts: appsody-controller-0.3.2:/.appsody
[Debug] docker.io/dev.local/java-spring-boot2:0.3 image pulled status: true
[Debug] Image has been pulled already: docker.io/dev.local/java-spring-boot2:0.3
[Debug] Exposed ports provided by the docker file[35729 5005 8080 8443]
[Debug] Environment variable found cached: PORT Value: 8080
[Debug] Container port set to: 8080
[Debug] Published ports provided as inputs: []
[Debug] Environment variable found cached: APPSODY_USER_RUN_AS_LOCAL Value: true
[Debug] Attempting to start image docker.io/dev.local/java-spring-boot2:0.3 with container name appsody-build-simple-test755797221-dev
[Info] Running command: docker run --rm -p 35729:35729 -p 5005:5005 -p 8080:8080 -p 8443:8443 --name appsody-build-simple-test755797221-dev -u 1000:1001 -e APPSODY_USER=1000 -e APPSODY_GROUP=1001 -v /tmp/appsody-build-simple-test755797221/.:/project/user-app -v /home/tnixa/.m2/repository:/mvn/repository -v appsody-controller-0.3.2:/.appsody -t --entrypoint /.appsody/appsody-controller docker.io/dev.local/java-spring-boot2:0.3 --mode=test -v --no-watcher
[Container] File watching has been turned off at the request of the CLI.
[Container] [ControllerDebug] Running Appsody Controller version 0.3.2
[Container] [ControllerDebug] Appsody Controller environment variables: map[APPSODY_DEBUG:/project/java-spring-boot2-build.sh debug APPSODY_DEBUG_KILL:false APPSODY_DEBUG_ON_CHANGE:/project/java-spring-boot2-build.sh recompile APPSODY_INSTALL: APPSODY_MOUNTS:.:/project/user-app;~/.m2/repository:/mvn/repository APPSODY_PREP: APPSODY_RUN:/project/java-spring-boot2-build.sh run APPSODY_RUN_KILL:false APPSODY_RUN_ON_CHANGE:/project/java-spring-boot2-build.sh recompile APPSODY_TEST:/project/java-spring-boot2-build.sh test APPSODY_TEST_KILL:true APPSODY_TEST_ON_CHANGE: APPSODY_WATCH_DIR:/project/user-app/src APPSODY_WATCH_IGNORE_DIR: APPSODY_WATCH_INTERVAL:2s APPSODY_WATCH_REGEX:(^.*\.java$)|(^.*\.properties$)|(^.*\.yaml$)|(^.*\.html$)|(^.*\.sql$)|(^.*\.js$)|(^.*\.properties$)]
[Container] [ControllerDebug] APPSODY_DEBUG,APPSODY_TEST or APPSODY_RUN command : /project/java-spring-boot2-build.sh test
[Container] [ControllerDebug] File change command:
[Container] [ControllerDebug] The fileChangeCommand environment variable APPSODY_RUN/DEBUG/TEST_ON_CHANGE is unspecified or file watching was disabled by the CLI.
[Container] [ControllerDebug] Running APPSODY_RUN,APPSODY_DEBUG or APPSODY_TEST sync: /project/java-spring-boot2-build.sh test
[Container] [ControllerDebug] Running command:  /project/java-spring-boot2-build.sh test for process type APPSODY_RUN/DEBUG/TEST
[Container] [ControllerDebug] Set workdir:  /project/user-app
[Container] Running command:  /project/java-spring-boot2-build.sh test
[Container] [ControllerDebug] New process created with pid 15
[Container] [ControllerDebug] Started RUN/DEBUG/TEST process
[Container] Installing parent dev.appsody:spring-boot2-stack:0.3.20
[Container] > mvn install -q -f /project/appsody-boot2-pom.xml
[Container] [ERROR] [ERROR] Some problems were encountered while processing the POMs:
[Container] [ERROR] Non-resolvable import POM: Could not transfer artifact com.fasterxml.jackson:jackson-bom:pom:2.9.9 from/to central (https://repo.maven.apache.org/maven2): /mvn/repository/com/fasterxml/jackson/jackson-bom/2.9.9/jackson-bom-2.9.9.pom.part.lock (No such file or directory) @ org.springframework.boot:spring-boot-dependencies:2.1.6.RELEASE, /mvn/repository/org/springframework/boot/spring-boot-dependencies/2.1.6.RELEASE/spring-boot-dependencies-2.1.6.RELEASE.pom, line 606, column 19
[Container] [ERROR] Non-resolvable import POM: Could not transfer artifact org.glassfish.jersey:jersey-bom:pom:2.27 from/to central (https://repo.maven.apache.org/maven2): /mvn/repository/org/glassfish/jersey/jersey-bom/2.27/jersey-bom-2.27.pom.part.lock (No such file or directory) @ org.springframework.boot:spring-boot-dependencies:2.1.6.RELEASE, /mvn/repository/org/springframework/boot/spring-boot-dependencies/2.1.6.RELEASE/spring-boot-dependencies-2.1.6.RELEASE.pom, line 2066, column 19
[Container]  @
[Container] [ERROR] The build could not read 1 project -> [Help 1]
[Container] [ERROR]
[Container] [ERROR]   The project dev.appsody:spring-boot2-stack:0.3.20 (/project/appsody-boot2-pom.xml) has 2 errors
[Container] [ERROR]     Non-resolvable import POM: Could not transfer artifact com.fasterxml.jackson:jackson-bom:pom:2.9.9 from/to central (https://repo.maven.apache.org/maven2): /mvn/repository/com/fasterxml/jackson/jackson-bom/2.9.9/jackson-bom-2.9.9.pom.part.lock (No such file or directory) @ org.springframework.boot:spring-boot-dependencies:2.1.6.RELEASE, /mvn/repository/org/springframework/boot/spring-boot-dependencies/2.1.6.RELEASE/spring-boot-dependencies-2.1.6.RELEASE.pom, line 606, column 19 -> [Help 2]
[Container] [ERROR]     Non-resolvable import POM: Could not transfer artifact org.glassfish.jersey:jersey-bom:pom:2.27 from/to central (https://repo.maven.apache.org/maven2): /mvn/repository/org/glassfish/jersey/jersey-bom/2.27/jersey-bom-2.27.pom.part.lock (No such file or directory) @ org.springframework.boot:spring-boot-dependencies:2.1.6.RELEASE, /mvn/repository/org/springframework/boot/spring-boot-dependencies/2.1.6.RELEASE/spring-boot-dependencies-2.1.6.RELEASE.pom, line 2066, column 19 -> [Help 2]

Same error is happening for the default template.
This failure is not happening on Windows or macOS, just RHEL 7.7
To Reproduce
Steps to reproduce the behavior:

clone the stacks repo
cd incubator/java-spring-boot2
appsody stack validate
See error

Environment Details (please complete the following information):

OS: [e.g. iOS] RHEL Enterprise 7.7

If applicable please specify:

CLI version: 0.5.2
Stack you are using (including the version): java-spring-boot2

Does it happen repeatedly or just once?

@ebullient happens every time i try it

Ok. So the stage where this is failing is when running/testing locally "in the foreground" .. it is having trouble reading/writing files to the mounted .m2 directory.
I don't know whether or not RHEL has different permission requirements for docker to be able to write to local file system mounts, or if there are other read/write latency issues that could be causing this.

@tnixa .. did you figure anything else out? Was this just an issue with SE?

@ebullient I was able to recreate this just now on my RHEL fyre VM. This VM has java jdk and is not SE.
I believe we were thinking this could be an issue with having java install but not a jdk or an issue with SELinux but these do not appear to be the cause of the problem.

that mvn install is handled by the stack container, what is, or isn't, installed in the host OS doesn't matter. What does matter is whether or not maven central can be reached, and whether or not appsody has permission to write to the ~/.m2 directory.

Working with @ebullient on this today and it seems the problem is due to having root owned files in the ~/.m2/repository directory. I removed the ~/.m2 directory and then reran the appsody stack validate and it was successful and there were not any root owned files in the ~/.m2/repository I discovered the java-microprofile stack is creating the root owned files and I created issue #593


LDA Model incredibly slow, even in low dimension

I've been trying to write out an LDA model using Turing, but sampling is incredibly slow. I was only trying to use one of the 20 Newsgroups dataset. I pared it down to 2 topics and 2 documents, just to see if it would sample at a reasonable rate, but it's still incredibly slow.
Can anyone take a look at this, and point me at something I'm doing incorrectly?

K: 2, number of topics
D: 2, number of documents
V: 160, number of tokens in the vocabulary
N: 290, number of tokens in all documents (i.e. length of data)
w: Vector{int}, token index of the word in the vocabulary
d: Vector{int}, document index of the word

A document is transformed from a list of tokens into two vectors: w and d like so:
d1 = [1, 2, 3]
d2 = [2, 1, 1]
w = [1, 2, 3, 2, 1, 1]
d = [1, 1, 1, 2, 2, 2]
K = 2
V = length(unique(word_labels))
D = length(unique(doc_labels))
N = length(word_labels)

@model lda(d=Vector{Int}(undef, N), w=Vector{Int}(undef, N)) = begin
    ϕ = Vector{Vector{Real}}(undef, K)
    for i in 1:K
        ϕ[i] ~ Dirichlet(ones(V) / V)
    end

    θ = Vector{Vector{Real}}(undef, D)
    for i in 1:D
        θ[i] ~ Dirichlet(ones(K) / K)
    end

    z = tzeros(Int, N)

    for i in 1:N
        z[i] ~ Categorical(θ[d[i]])
        w[i] ~ Categorical(ϕ[d[i]])
    end
end

g = Gibbs(1000, HMC(1, 0.2, 3, :ϕ, :θ), PG(1, 1, :z));
chains = sample(lda(doc_labels, word_labels), g)

In my previous experiments, using an uncollapsed LDA implementation is indeed slow. There are a few tricks you can use to make it faster

using the vectorised syntax for phi and theta inside the model

  theta = Matrix{Real}(K, M)
  theta ~ [Dirichlet(alpha)]

  phi = Matrix{Real}(V, K)
  phi ~ [Dirichlet(beta)]

implement a collapsed version

You can marginlise out z and increase the log-joint by some matrix operations. I'm pasting my previous code blow:

  phi_dot_theta = log.(phi * theta)
  logjoint += mapreduce(n->phi_dot_theta[w[n], doc[n]], +, 1:N)

However, with the Turing's new compiler. This is currently not possible as we don't provide an interface to manipulate the log-joint to users any more. @mohamed82008 I think we should either let users get access to vi or provide an interface to increase the log-joint in the model, because there are many tricks user can do to manipulate the log-joint to get a huge performance gain.

Other side notes:

In Turing (or Julia?), the performance is more sensitive to K, D and V but not N. As native Julia codes are very fast the evaluate the likelihood.
We previously obtained very good performance on LDA that is better than Stan. However, at that time Turing's AD is based on ReverseDiff.jl, which has some code optimisation leads to a good performance gain (https://github.com/JuliaDiff/ReverseDiff.jl/issues/102). But we now switch to Flux.jl as our AD backend so I don't think we are still that fast. @mohamed82008 do you think the performance gain we obtained before is because ReverseDiff somehow compiles the code and makes it type stable?

@mohamed82008 do you think the performance gain we obtained before is because ReverseDiff somehow compiles the code and makes it type stable?

Last I checked, ReverseDiff and Zygote were both type stable, Flux AD was not. But I did not benchmark them against each other.

@mohamed82008 I think we should either let users get access to vi or provide an interface to increase the log-joint in the model,

I am OK with the first. There is nothing wrong with reserved words, we can make __vi__ as one and use that for the VarInfo. @yebai and @willtebbutt any objections?

So for a collapsed version, if theta is DxK and phi is KxV wouldn’t this be the same as doing the log likelihood trick:
word_dist = theta * phi
for i in 1:N
W ~ Categorical(word_dist[doc_idx[i]])
end

Yes this trick certainly works, with a bit tweak, due to the fact that Categorical in Distributions doesn't support AD yet. See a complete example below
using Turing

struct CategoricalReal<: Distributions.DiscreteUnivariateDistribution
    p
end

function Distributions.logpdf(d::CategoricalReal, k::Int64)
    return log(d.p[k])
end

@model lda_collapsed(K, V, M, N, w, doc, beta, alpha) = begin
    theta = Matrix{Real}(undef, K, M)
    for m = 1:M
        theta[:,m] ~ Dirichlet(alpha)
    end

    phi = Matrix{Real}(undef, V, K)
    for k = 1:K
        phi[:,k] ~ Dirichlet(beta)
    end

    word_dist = phi * theta

    for n = 1:N
        w[n] ~ CategoricalReal(word_dist[:,doc[n]])
    end
end

Maybe re-run the model on the master branch?
cc @trappmartin @htsadiq

Just check the inference time with the same hyper-parameter in the original question (D = 2, K = 2, V = 160, N = 290) and the current Turing (v0.21.5) is much faster than before.
I'm putting a minimal example below to track the performance.
using Distributions, Turing
Turing.setadbackend(:tracker)

function make_data(D, K, V, N, α, η)
    β = Matrix{Float64}(undef, V, K)
    for k in 1:K
        β[:,k] .= rand(Dirichlet(η))
    end

    θ = Matrix{Float64}(undef, K, D)
    z = Vector{Int}(undef, D * N)
    w = Vector{Int}(undef, D * N)
    doc = Vector{Int}(undef, D * N)
    i = 0
    for d in 1:D
        θ[:,d] .= rand(Dirichlet(α))
        for n in 1:N
            i += 1
            z[i] = rand(Categorical(θ[:,d]))
            w[i] = rand(Categorical(β[:,z[i]]))
            doc[i] = d
        end
    end
    return (D=D, K=K, V=V, N=N, α=α, η=η, z=z, w=w, doc=doc, θ=θ, β=β)
end

data = let D = 2, K = 2, V = 160, N = 290
    make_data(D, K, V, N, ones(K), ones(V))
end

# LDA with vectorization and manual log-density accumulation
@model function LatentDirichletAllocationVectorizedCollapsedMannual(
    D, K, V, α, η, w, doc
)
    β ~ filldist(Dirichlet(η), K)
    θ ~ filldist(Dirichlet(α), D)

    log_product = log.(β * θ)
    Turing.@addlogprob! sum(log_product[CartesianIndex.(w, doc)])
    # Above is equivalent to below
    #product = β * θ
    #dist = [Categorical(product[:,i]) for i in 1:D]
    #w ~ arraydist([dist[doc[i]] for i in 1:length(doc)])
end

lda = LatentDirichletAllocationVectorizedCollapsedMannual(data.D, data.K, data.V, data.α, data.η, data.w, data.doc)

@time chain = sample(lda, HMC(0.05, 10), 2_000) # => 57s on my laptop

which finishes within 1 minutes on my laptop.
We may want to track this somewhere (and somehow automatically) but I think this issue can be closed.

Maybe create a benchmarking page on the new website? LDA is a very good case to include I think.

I'm very impressed by the speed increase that's happened over the last three years. I'd forgotten about this, but the fact that the un-collapsed LDA sample works so well now is a testament to all the great work you all are doing!


'Back-to-top' link for the ReadMe.md

A back-to-top link will improve navigation and ease of use.

I would to like to add a 'back-to-top' link for the ReadMe.md.
I am contributing under GSSoC'23 .  Could this issue be assigned to me@ShwetKhatri2001?

@VSatwika I'd suggest if you can add Table of Contents having links to the sections currently present in README.md instead of Back to Top buttons, since the sections are not too descriptive currently to have Back to Top links, but having a list of titles of all the sections to be navigated can help. Let me know if you'd like to work on that.


Can r10k run after specific provision script?

I've got a bootstrapping script which builds a puppetfile based on module dependencies, however I can't seem to find a way to get r10k to run after this provisioning script. It always wants to run immediately. Is there a method to get it to run after a specific provisioner?

@jruybal
Short answer: Don't dynamically generate your Puppetfile through Vagrant. If you need to dynamically generate it, trigger that script manually and then commit the result to the git repo.
Long answer:
Unfortunately, I don't think there is. My memory on this next point is a bit hazy, so some of this might not be 100% correct. Also, it's honestly possible that there is a better way to do this, that I missed. But there's really precious little documentation about how Vagrant plugins work or how to write them...
The way this works is a bit complicated, but the gist is that Vagrant has two "phases" of running plugins and provisioners; (config) validation and provisioning. There doesn't seem to be any way to force the order that plugins run in, so my only choice was to have vagrant-r10k do its actual deploy in the validation phase. As a result, vagrant-r10k will run before any provisioner.
If this bootstrapping script generates the Puppetfile, and presumably runs on your host (not in the Vagrant guest), is there a reason why it needs to be a provisioning script?
This may or may not be workable for you: maybe just don't use it as a provisioning script, but rather execute it at the top of your Vagrantfile, before the Vagrant.configure block; IIRC that should run before Vagrant does anything, though it will also run for any vagrant command.
Another option would be to turn this into a feature request, and add a configuration option to vagrant-r10k for a block of code to run at the very beginning of the r10k stuff. I'm not sure how quickly I could get that done, and how much I like the idea...
However, I'm not sure what your exact use case is, but I'm very hesitant to do a whole lot to enable dynamic generation of Puppetfiles, which is very likely to cause problems. Puppetfiles are like any other language's dependency specified (requirements.txt in python, Gemfile in ruby, pom.xml for java/maven) and will almost certainly break things eventually if they're generated dynamically rather than being manually reviewed and committed with the code.

Thanks for the detailed explanation. This makes a lot more sense now.
Our dynamic generation of the puppetfile is nothing more than looking at the module's metadata.json files for dependencies and adding the name and version number into the puppetfile. This only used in our development environment. These puppetfiles and their managed modules are kept out of the repo in an effort to keep the repo from exploding.

Ok, that makes sense. For the record, if it were me, I'd do one of these things, depending on which is easiest to implement in your environment:

Have the Puppetfile generation script run manually when metadata.json is changed.
That, but have a test or git update hook that rejects the commit if metadata.json changes and the Puppetfile doesn't.
Do the generation in your CI system; when a commit changes metadata.json, have it run the Puppetfile generation script and commit the result back to the repo.
Push for me to give vagrant-r10k the ability to execute an aribtrary block of Ruby code before it runs r10k.


[WFLY-16189]: Add messaging-activemq transformation to the 13.1 mgmt api version, along with parsing support.

Adding Messaging 13.1 management API
Updating transformers to take 13.1 into account

Jira: https://issues.redhat.com/browse/WFLY-16189

retest this please


Rename SpectralSolverParameters to PoissonSolver and improve solver documentation

This PR addresses #106 and #102, renaming SpectralSolverParameters to PoissonSolver (and similarly for GPU versions).
To do before merging:

improve documentation
change the name of the model field ssp to something more appropriate.

ssp has been changed to poisson_solver and documentation changes have been pushed. @ali-ramadhan, do you mind taking a look? (Feel free to merge if everything is satisfactory.)

Looks great! Looks like it passes on Travis which is good as the Poisson solver is tested a bit more comprehensively than the rest of the code.
Thanks for updating the documentation, that was definitely an important change.
Merging and I'll let you close #102 and #106 if you feel they've been resolved.


db.getStore().compact() hangs?

Hi,
thanks for the library!
I'm trying to add roughly 100 billion strings to a database.
I create a database and treeset and call compact roughly every 300 million strings:
 db = DBMaker                 .fileDB(file)                 .fileMmapEnable()                 .allocateIncrement(512 * 1024 * 1024)                 .make(); NavigableSet<String>treeSet = (NavigableSet<String>) db                 .treeSet("treeSet_" + name+"_"+k)                 .serializer(new SerializerCompressionWrapper(Serializer.STRING))                 .createOrOpen();
This worked fine, but after inserting roughly 2^32 strings the next call of db.getStore().compact(); seemed to "hang". With hanging I mean the CPU utilization is almost zero and there is also no disk activity.
After that I thought maybe I'm only allowed to add 2^32 (max int) strings and changed my code to create 15 databasefiles, each with 10 tree sets. That worked for some time but now that I have added roughly 70 billion strings a OutOfMemoryException was thrown while compacting. After that I killed the program and started again from my backup, but added a 250GB swapfile to the 64GB RAM. This time the compact call seems to hang again (no error/exception). At least for the last 4 hours there was no disk or CPU activity. I'm using mapdb 3.0.8.
Is there a limit to how many strings I can add? Or am I doing something else wrong?
Edit: For each databasefile I have a own thread. The call to compact() is locked by a semaphore, so only one compact() call is executed at a time.

Tried again and got a stack trace:
java.lang.OutOfMemoryError: Java heap space         at org.mapdb.serializer.SerializerByteArrayNoSize.deserialize(SerializerByteArrayNoSize.java:23)         at org.mapdb.serializer.SerializerByteArrayNoSize.deserialize(SerializerByteArrayNoSize.java:14)         at org.mapdb.StoreDirectAbstract.deserialize(StoreDirectAbstract.kt:229)         at org.mapdb.StoreDirect.get(StoreDirect.kt:546)         at org.mapdb.StoreDirect.compact(StoreDirect.kt:771)         at Utils.Compact.compact(Compact.java:56)         at Utils.Compact.call(Compact.java:40)         at Utils.Compact.call(Compact.java:16)         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)         at java.base/java.lang.Thread.run(Thread.java:830)
Forgot to update Xmx value after adding the swap. Will update when I know more.

hi, compaction loads some data into memory. That is causing OOEMs. There is no workaround for that, sorry

Hi, ok thanks for the reply.
With high Xmx value I get the following exception:
Exception in thread "main" java.util.concurrent.ExecutionException: org.mapdb.DBException$PointerChecksumBroken: Broken bit parity         at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)         at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)         at MainParallel4.add(MainParallel4.java:153)         at MainParallel4.main(MainParallel4.java:67) Caused by: org.mapdb.DBException$PointerChecksumBroken: Broken bit parity         at org.mapdb.DataIO.parity1Get(DataIO.java:440)         at org.mapdb.StoreDirect.getIndexVal(StoreDirect.kt:131)         at org.mapdb.StoreDirect.get(StoreDirect.kt:523)         at org.mapdb.BTreeMap.getNode(BTreeMap.kt:800)         at org.mapdb.BTreeMap.access$getNode(BTreeMap.kt:72)         at org.mapdb.BTreeMap$BTreeIterator.advanceFrom(BTreeMap.kt:1031)         at org.mapdb.BTreeMap$BTreeIterator.advance(BTreeMap.kt:1050)         at org.mapdb.BTreeMap$keyIterator$1.next(BTreeMap.kt:1205)         at org.mapdb.BTreeMap.sizeLong(BTreeMap.kt:908)         at org.mapdb.BTreeMap.getSize(BTreeMap.kt:898)         at org.mapdb.BTreeMap.size(BTreeMap.kt:72)         at org.mapdb.BTreeMapJava$KeySet.size(BTreeMapJava.java:407)         at Utils.AddPWNew.call(AddPWNew.java:78)         at Utils.AddPWNew.call(AddPWNew.java:16)         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)         at java.base/java.lang.Thread.run(Thread.java:830)
Is the "Broken bit parity" a consequence of me adding to much data or am I doing something else wrong?


Fix fsgroup permission for pvc

Thanks @tamalsaha for your PR. We have provided interface so that you can provide your value during the installation - https://github.com/open-cluster-management-io/multicluster-controlplane/blob/65996596b295e0e438f198eb728d0ebf7e449927/charts/multicluster-controlplane/values.yaml#L48 Does it make sense?

I need to set fsGroup which can only be set in the podSecurityContext not containerSecurityContext.

This pr is not needed anymore. But if you think this pr adds an example, consider merging it.


[FLINK-21664][table-api] Support STATEMENT SET syntax in TableEnvironment

What is the purpose of the change
Currently we have discussed the grammar about multi-line statements as follows:
BEGIN STATEMENT SET;
INSERT INTO ... SELECT ...;
INSERT INTO ... SELECT ...;
END;

SqlParser should support STATEMENT SET syntax in TableEnvironment.
Brief change log

Add SqlStatementSet to support STATEMENT SET syntax for SqlParser.

Verifying this change

FlinkSqlParserImplTest adds testStatementSetWithSingleInsertInto, testStatementSetWithMultiInsertInto, testStatementSetWithoutInsertInto and testStatementSetWithCreateTable to verify whether SqlParser supports the STATEMENT SET syntax.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Thanks for your contribution @SteNicholas.
I have some thoughts about this PR. Because our goal is to submit statement set in the sql client. However,  the Executor is just a wrapper of the TableEnvironment that can notice the Operation rather than SqlNode.  Therefore, we need to introduce operations.
The second question is how sql client submits statement. In the FLIP, we reach consensus that the desired behaviour looks like
Flink SQL> BEGIN STATEMENT SET;

[Info] Begin the statement set.

Flink SQL> INSERT INTO emps1 SELECT * FROM emps(x, y);

[Info] Add the statement into the statement set.

Flink SQL> INSERT INTO emps2 SELECT * FROM emps(x, y);

[Info] Add the statement into the statement set.

Flink SQL> END;

[Info] Submitting SQL statement set to the cluster...

I think the proposed grammer may not achieve the final goal.

@fsk119 , thanks for your detailed review. The question you mentioned above has already been discussed by @wuchong . I would like to unify the parser behavior of TableEnvironment and SQL Client.

@wuchong @fsk119 , I have followed the statement set syntax as follows:
BEGIN STATEMENT SET;
INSERT INTO xx SELECT * FROM xxx;
END;

Please help to review this update for the statement set syntax.

@wuchong , thanks for detailed review. I have followed your comments and only supported the statement set parser. Please help to review again.


Make StaticCell less complex to use

Also made some tweaks to socket

Actually, not sure about using static_cell! for error types; we wouldn't want properties on the exception types to be carried across sub-interpreters.

Although it looks like that's not restricted for builtin types either:
>>>>> type.a = 1
>>>>>

>>>>> type.a = 1
>>>>>

this looks like a bug. does this type marked as HAS_DICT?

Well user classes can be edited like that:
class A: pass
A.foo = 1

But I think we probably need a tpflag to prevent built-in types from being mutated


Assert manual synchronized for CI

Solve the same issue as below.
https://github.com/rubocop-hq/rubocop-performance/pull/62
Therefore this PR imports the following code from RuboCop core.
https://github.com/rubocop-hq/rubocop/blob/v0.71.0/tasks/cops_documentation.rake#L234-L246
Other Information
Built-in Environment Variable CI by default true on CircleCI.
https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

👍


Adds grappling gun

https://github.com/space-wizards/space-station-14/assets/31366439/5d5ac376-0ec9-488b-ad20-c9e14c91753e
:cl:

add: Added a grappling gun

please make it so you can grapple onto an FTLing object

then it has issue of syndies grappling evac (instead of putting rods) for easy escape greentext

then it has issue of syndies grappling evac (instead of putting rods) for easy escape greentext

then it has issue of syndies grappling evac (instead of putting rods) for easy escape greentext

Make it so you’re rapidly damaged in FTL when outside or that shrimply doesn’t count for the objective
you not ON the shuttle


qa_crowbarsetup.sh: Add SES 2 repos on admin server for Cloud 6+

We keep the SES 1.0 repos for now as the product hasn't move to SES 2
yet; this patch will only enable people to work on SES 2 integration.

+1

+1