only set count if there is no end date to avoid internally limiting results

Should have been closed a long time ago, we no longer limit results if there is an end date.


Parallax is still applied even when parallax is set to false

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Swiper Version: 4.4.6

Platform/Target and Browser Versions: macOS

What you did
Applied parallax data-swiper-parallax-x to an element yet set parallax to false when initializing swiper.
Expected Behavior
Parallax is not applied.
Actual Behavior
Parallax is applied.

Im also experiencing this. I am attempting to have 2 different configurations for desktop & mobile (need to change more than can be configured in the breakpoints object) so I have a media query listener setup to destroy the swiper and re-init a new one, whenever I start as a desktop width swiper and resize down to mobile, the re-init keeps the parallax on even though I have parallax: false in the mobile config.


Update castling rules

The existing implementation always measured the target squares (if potentially occupied), while there is supposed to be an EXCLUDED variant that measures and a BASIC variant that doesn't. The BASIC variant is needed because you are allowed to castle without measuring if there is a same-color rook in superposition on the rook's target square.


[r] Build R/C++ code with shared rather than static libtiledbsoma

Split out from #1277 .
PR #1280 has CI fail on MacOS, and skipped on Linux -- not clear it works either place.
This needs debugging.

Nit:  It's not 'Rcpp code' .  It's native (C/C++) code in an R package that happens to use Rcpp for glue.

#1302 is merged


Possible upgrade to the latest Fontawesome library with material design  font ?

Hi
I see,  you are using an old library of font awesome.  I still don't use the new,  but now,  there are a lot of font in material design etc available with the last version.  I don't know if that can interest you but it's a suggestion to upgrade :)

Fontawesome is only used in the demo, and it's not part of JFoenix (upgrading fontawesome library is not part of JFoenix development). There is a JFoenix control called SVGGlyph that you can use to show any svg image in your application.


Historic Mountain View boundaries

The City of Mountain View maintains a GIS layer of annexation areas. This dataset is in the public domain as a work of a California government agency. Each area comes with two dates: the date on which the annexation ordinance was filed by the city, and the date on which it was enrolled into the county’s resolution book. For OpenHistoricalMap, we can create boundary relations based on these areas, similar to San José in #28, and tag them with one of the dates. Mountain View doesn’t border San José, so boundary conflation won’t be necessary just yet.

@jeffreyameyer imported this dataset last August. However, the tags on some of the features need to be redone. For example, way 199,589,446 has lots of junk tags autogenerated from ArcGIS. All the ways need to be converted into boundary relations with inner and outer rings and added to a chronology relation.

Yes - some of those tags are junk (not sure why I left the ShapeST* - I can clean those up. Some of the other metadata may be useful. I'll do a quick cleanup.


Refactor FluidWarpMod

This is an attempt to fix issues with fluid warp suddenly failing to push fluids at seemingly random times. I've done quite a bit of refactoring to make things simpler. Some functionality has also changed.

Split up the warp buildings into Providers/Requesters
Logically, Providers now push out to requesters. This allows us to split the provider's mass evenly to all requesters. This fixes possibility that you have too many requesters for each providers, leaving some requesters with nothing, making it look like its not hooked up at all. This way, it behaves like regular pipes which split off to its consumers (right? I'm new to ONI, lol).
Removed power requirement for now. Can add later?

One thing I was looking into was adding a 'Status' label on the gates that displays how many gates are connecting to the same channel. Could also add status label for when the gate can't push any fluid or something. Couldn't figure out how to add status labels though, could use help on this.
I've done some basic testing in debug mode. I'd like to get some more testing in longer games, which I will also do myself when I get time. There is some sub-optimal code when it comes to performance. I don't expect it to create any lag, but there can be improvements made if it does. Please report any issues here!

Nice! I really like that approach. I'll give it a test as soon as I can get the new mod system working on my Mac )

Well from my testing, the mods been working perfectly now. Feel free to merge.

I can't make it work on my macBook. The mod crashes on load. Trying to debug now

Okay fixed the wrong animation.
Those other two comments are about code that is already removed.

Regarding two commented snippets - I mean that it is generally a good practice to delete code when you want to remove it, not comment it out. Just to keep the codebase clean.
Anyway... Good job! Thank you!

Sorry, @Blindfold and @makotech222 I've had this mod abandoned lately.
Thank you both for your efforts.
I both of you agree, I'll try to upload this mod to Steam this week.


Make ssh and remote desktop buttons disable if p2p is in connecting state, or in failed state

Right now ssh and desktop buttons are active even if we have not p2p connection or it failed.
Need to correct that.

duplicate of https://github.com/subutai-io/control-center/issues/683


i need this but where is it

What is your question?
ayo where the camera move script??? i need it for something on my main pc that i dont have

it's hardcoded

it's hardcoded

ik but like where is it in (assuming its in playstate.hx)

yeah

yeah

what specific line tho

it's on many lines, just search around with camFollow

ok thanks ill keep that in mind once i get my main pc back

np


code health sanitytest

[x] tests are added or updated

Update sanitytest to use the test infrastructure

Changed to single ifs

Pushed. Thanks.


bug related to nokogiri

While building dockerfile, we noticed that there is an http error 403 related to the downloading of file : https://api.rubygems.org/quick/Marshal.4.8/nokogiri-1.13.0-x64-unknown.gemspec.rz (see logs here)

opened twice.


DF not recognizing Date as a column

Using ticker.history(), then trying to access 'Date' gives you a keyerror. Additionally, using row[0] gives you the open price.

When you convert DF to Dict
{
'Open': {Timestamp('2020-12-14 00:00:00'):<PHONE_NUMBER>741211},
'High': {Timestamp('2020-12-14 00:00:00'):<PHONE_NUMBER>741211},
'Low': {Timestamp('2020-12-14 00:00:00'):<PHONE_NUMBER>9482422},
'Close': {Timestamp('2020-12-14 00:00:00'):<PHONE_NUMBER>7929688},
'Volume': {Timestamp('2020-12-14 00:00:00'): 79075988},
'Dividends': {Timestamp('2020-12-14 00:00:00'): 0.0},
'Stock Splits': {Timestamp('2020-12-14 00:00:00'): 0.0}
}

This is a Pandas question, no yfinance. You're trying to access an index ('Date') by its name (instead of the index attribute, as in df.index). See Pandas docs or stackoverflow for more info
https://stackoverflow.com/questions/52139506/accessing-a-pandas-index-like-a-regular-column

@simonvdv thank you!


Allow forwarding of specified port ranges to all interfaces

This allows to expose e.g. an ingress port outside of the local host while still forwarding other ports only to localhost.
Example:
allInterfaces:
- port: 443
- port: 4000
  until: 4999

I'm not quite sure how this will interact with #45, but I think/hope it will be independent (the filtering of incoming connections would be done via iptables inside the guest?).
I'm also not really happy about the allInterfaces key name, but couldn't come up with anything better.

I'm also not really happy about the allInterfaces key name, but couldn't come up with anything better.

What about ports (or portForwards) ?
ports:
- guestPort: 443
  hostIP: "<IP_ADDRESS>" # overrides the default value "<IP_ADDRESS>"
# default: hostPort: 443
# default: guestIP: "<IP_ADDRESS>" (implementation can be done later, but we have to reserve the field name now)
# default: proto: "tcp" (same as above)

- guestPortRange: [4000, 4999]
  hostIP:  "<IP_ADDRESS>" # overrides the default value "<IP_ADDRESS>"
# default: hostPortRange: [4000, 4999]
# default: guestIP: "<IP_ADDRESS>"
# default: proto: "tcp"

- guestPort: 80
  hostPort: 8080 # overrides the default value 80
# default: hostIP: "<IP_ADDRESS>"
# default: guestIP: "<IP_ADDRESS>"
# default: proto: "tcp"

I'm not quite sure how this will interact with #45, but I think/hope it will be independent (the filtering of incoming connections would be done via iptables inside the guest?).

No, iptables inside the guest cannot be used, as the guest is unaware of the src IP.
So the filtering will be implemented in a usermode proxy process on the host.
I assume #45 will not need a new YAML field. "Try ssh -L first and then fall back to our own forwarderwould be fine. We can also consider completely removingssh -L`, depending on benchmarking result.

What about ports (or portForwards) ?

Yes, much better and more flexible. I've updated the PR to match your samples.

Sorry, did one more push to fix a trivial error in an error message:
        case port > 65535:
-               return errors.Errorf("field `%s` must be < 65535", field)
+               return errors.Errorf("field `%s` must be < 65536", field)

But now I'm really done...

@AkihiroSuda I've been wondering how GuestIP is supposed to be used. Is given that we only forward ports from <IP_ADDRESS> or <IP_ADDRESS>, is there a reason to every use anything else but <IP_ADDRESS> as the guest IP?
Even if the port is bound to ::1 it is still reachable via <IP_ADDRESS> as well, as both addresses are just aliases on the lo adapter.
I tried to make the logic deal with GuestIP as well, but it quickly got confusing, and I don't actually see any functionality it would give us, so I dropped it again. Maybe this will be different when we get an actual IP address via vde_vmnet?

I guess the "guestIP" isn't going to be used in most cases. The field is only useful when an application inside VM calls bind("192.168.X.X:Y").

I'd like to see unit tests and/or integration tests, but tests can be added later

I've been trying to create integration tests today, but can't make them work reliably because there is no way to flush the hostagent logs to disk. While looking into this I noticed that logrus is in maintenance mode, but all the newer libraries don't seem to have a Flush API either (but maybe one can implement it at the app level, which doesn't seem to be possible with logrus).
Anyways, will change the tests to shut down the instance, and analyze the logs afterwards.
BTW, I noticed that virtually all the output from the hostagent except for status messages goes to stderr. If this is intentional, then I think it would make more sense to just have a single log stream for the hostagent.

I've been trying to create integration tests today, but can't make them work reliably because there is no way to flush the hostagent logs to disk.

Implemented in commit hostagent: sync every (io.Writer).Write. Accidentally pushed to master without opening a PR. 😅
https://github.com/AkihiroSuda/lima/commit/722b7d1b1f38eaca397bf29f8f83062a72fc78d1

BTW, I noticed that virtually all the output from the hostagent except for status messages goes to stderr. If this is intentional, then I think it would make more sense to just have a single log stream for the hostagent.

Stdout is guaranteed to be unmarshallable as JSON lines, but stderr is no, because imported libraries may print something to stderr without using logrus. So we have to maintain the two streams.

Implemented in commit hostagent: sync every (io.Writer).Write.

Thanks! It turns out that I also mis-remembered that the guest-agent checks for port changes every second; it only checks every 3 seconds; so my strategic sleep 2 pauses need to be sleep 5 to make sure forwards are removed before they are added back...
I see that the lima-guestagent has a --tick option to specify a different poll frequency, but there is no way to configure it via lima. I'm inclined to add an env variable to set it (LIMA_GUESTAGENT_TICK?), or do you want it to be part of the yaml file?
(Wild idea for some distant time in the future: make the polling adaptive: poll more frequently whenever a new process or container is being created, as ports are typically opened early in the lifetime of a server process. Back off later, and especially when running on battery. Not sure if it is worth it; maybe it is just related to me seeing a demo using eBPF/LSM hooks yesterday 😄 ).

Stdout is guaranteed to be unmarshallable as JSON lines, but stderr is not,

Yes, but stdout seems to contain only 2 lines:
{"time":"2021-07-21T00:09:03.305227-07:00","status":{"sshLocalPort":60020}}
{"time":"2021-07-21T00:09:25.48178-07:00","status":{"running":true,"sshLocalPort":60020}}

I don't think they are important enough to require a separate JSON-unmarshallable file. Is there anything else written to it?
Anyways, my argument was that all the tracing and logging should go into stdout as well, and only errors should be written to stderr. Or maybe I'm still confused about what each file is supposed to be used for.

I see that the lima-guestagent has a --tick option to specify a different poll frequency, but there is no way to configure it via lima. I'm inclined to add an env variable to set it (LIMA_GUESTAGENT_TICK?), or do you want it to be part of the yaml file?

Either is fine to me, but I think we should clarify that the field is likely to be removed in future.

(Wild idea for some distant time in the future: make the polling adaptive: poll more frequently whenever a new process or container is being created, as ports are typically opened early in the lifetime of a server process. Back off later, and especially when running on battery. Not sure if it is worth it; maybe it is just related to me seeing a demo using eBPF/LSM hooks yesterday 😄 ).

Yes, actually I was planning to replace ticks with eBPF retprobes for bind, though it might be too much complicated.
We can also consider patching CNI portmap to inject a tick to the lima guestagent.


Upgrade to Support Ruby 3.1 and 3.2

We updated the library to keep in line with the upstream branch. Also, we drop support for Ruby <= 3.0 since the upstream one only support Ruby 3.1 and above

Dropping support of html-pipeline-rouge_filter and switching back to upstream recommendation to use HTML::Pipeline's built-in SyntaxHighlightFilter


Options do not update

Modifying the options does not take effect.

Affects classic and wrath classic.

Fixed in v2.2.12


Add cross-compilation for shipping service

Changes
Related to #709, this enables cross-compilation (arm64 target on amd64 build) for the github build workflow. It brings down the build time for the shipping service on both platforms to ~6min (from 1h14min). There are 2 disadvantages two that:

The Dockerfile becomes complicated (there is probably a way to optimize that, but look at that mess...)
The final image is not based on alpine anymore but debian slim, because cross-compiling with musl (and without glibc) didn't work for a variety of reasons, so the final image is bigger (97.8MB)

I raise this as a draft PR because this only becomes valuable when other long running builds are reduced accordingly, so merging it is not yet reasonable. The purpose of the PR right now is to discuss if the disadvantages (especially the first one) are worth the effort (assuming something similar can be done for the Quote, Payment & Currency-Services)

taking this out from Draft state for now. As a note: there is an alternative ways on how to structure this: Conditional stages using build arguments.
By introducing a build argument (e.g. BUILDER_TYPE) one can have 2 different stages for native & cross compilation, looks like this:
ARG BUILDER_TYPE=native
FROM rust:1.61 as builder-native
# native compilation
...
FROM --platform=${BUILDPLATFORM} rust:1.61 as builder-aarch64_on_x86
# cross compile
...
FROM builder-${BUILDER_TYPE} as builder
...
FROM debian:bullseye-slim as release
COPY --from=builder /app/target/release/shippingservice /app/shippingservice
...

The advantage is a clearer set of docker instructions per stage
The build argument needs to be set in the github workflow
Which one do people prefer?

131s vs. 105s for me.
When you do a full demo build the docker log goes a bit nuts but I think that's intended with the cross compilation

taking this out from Draft state for now. As a note: there is an alternative ways on how to structure this: Conditional stages using build arguments.
By introducing a build argument (e.g. BUILDER_TYPE) one can have 2 different stages for native & cross compilation, looks like this:
ARG BUILDER_TYPE=native
FROM rust:1.61 as builder-native
# native compilation
...
FROM --platform=${BUILDPLATFORM} rust:1.61 as builder-aarch64_on_x86
# cross compile
...
FROM builder-${BUILDER_TYPE} as builder
...
FROM debian:bullseye-slim as release
COPY --from=builder /app/target/release/shippingservice /app/shippingservice
...

The advantage is a clearer set of docker instructions per stage The build argument needs to be set in the github workflow
Which one do people prefer?

Honestly, I don't feel like the Dockerfile is that confusing as-is; I'd lean towards accepting it as stands in order to avoid adding a special case for the build scripts.