Server-side Rendering with React Components (Hybrid approach)

I am trying to setup asp.net core project with server-side rendering concept using react components(Hybrid way).
I can't use third party libraries in server-side rendering.
for example, https://reactstrap.github.io/  library throws this error.
"React.Exceptions.ReactScriptLoadException: Error while loading "~dist/server.bundle.js": Script Document [2]: Uncaught ReferenceError: Map is not defined at line: 2880 column: 69.
Line: 2880"
I attached the relevant screenshots here. please check this. Did I miss anything ?
error:

package file:

server-side component call in home view

startup file register

webpack config

expose-loader

mapping of server-side rendering

What JS engine are you using? I think the default fallback engine (internet
explorer) does not support Map, which is an ES2015 language features. Check
out the docs for switching to chakra core or v8, it’s possible you are
missing a runtime dependency such as VC2015 which is preventing the V8 DLLs
from loading.
On Mon, Jul 16, 2018 at 02:59, rkjeevakumar<EMAIL_ADDRESS>wrote:

I am trying to setup asp.net core project with server-side rendering
concept using react components(Hybrid way).
I can't use third party libraries in server-side rendering.
for example, https://reactstrap.github.io/ http://url library throws
this error.
"React.Exceptions.ReactScriptLoadException: Error while loading
"~dist/server.bundle.js": Script Document [2]: Uncaught ReferenceError: Map
is not defined at line: 2880 column: 69. Line: 2880"
I attached the relevant screenshots here. please check this. Did I miss
anything ?
error:
[image: error]
https://user-images.githubusercontent.com/8487243/42752492-a6347666-8920-11e8-8b64-1e0a6e1c4365.PNG
package file:
[image: package file]
https://user-images.githubusercontent.com/8487243/42752487-a558433a-8920-11e8-9e96-edf8302c993f.PNG
server-side component call in home view
[image: server-side component call in home view]
https://user-images.githubusercontent.com/8487243/42752489-a59163a4-8920-11e8-9bbc-094417728f30.PNG
startup file register
[image: startup file register]
https://user-images.githubusercontent.com/8487243/42752490-a5c5a4ac-8920-11e8-8b24-849f56a7a1b9.PNG
webpack config
[image: webpack config]
https://user-images.githubusercontent.com/8487243/42752491-a5fca308-8920-11e8-8457-c3e22a48934b.PNG
expose-loader
[image: expose-loader]
https://user-images.githubusercontent.com/8487243/42752493-a66759c8-8920-11e8-9a25-cc26ff5b0b06.PNG
mapping of server-side rendering
[image: mapping of server-side rendering]
https://user-images.githubusercontent.com/8487243/42752495-a69ff670-8920-11e8-85b5-ecf9a1999284.PNG
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/reactjs/React.NET/issues/572, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5hFnLH3CEQxhbPhMY2WRrG-oTZ7H_8ks5uHGP6gaJpZM4VQ2s0
.

https://github.com/Taritsyn/JavaScriptEngineSwitcher/wiki/Registration-of-JS-engines
I followed above link to add JS engine, but i got another issue Now i got this error
"HTTP Error 502.3 - Bad Gateway"
Can you please some other link to resolve this issue ? or some steps ...
Refer these screenshots...

Solution is to install ChakraCore NuGet package. Follow the steps in the documentation here https://reactjs.net/guides/chakracore.html.

You can check out the samples in this repo, they should all be working. At this point it doesn’t seem like this is a library bug so I’m closing this issue.. let me know if you have trouble getting the samples to run.


amcbldc: Add computation of RMS to thermal model

This PR improves the thermal model of the AMCBLDC by computing the moving RMS value of the Iq and Id currents.
This change is necessary to improve the physical accuracy of the model and therefore the estimation of the temperature.
The disspated power then becomes
$$
\dot{Q}  = (I_{q, RMS}^2 + I_{d, RMS}^2) R_L
$$
The moving RMS block uses exponential weighing to compute its output, with a decay factor of $\lambda=0.995$ . The value was chosen empirically with a tradeoff between response time and accuracy of the computation compared to the motion bandwidth.

The documentation says that:

The Moving RMS block computes the moving root mean square (RMS) of the input signal along each channel independently over time

So, probably, we can streamline the model with just one single Moving RMS block.
Did you try it out?

The documentationsays that:

The Moving RMS block computes the moving root mean square (RMS) of the input signal along each channel independently over time.

So, probably, we can streamline the model with just one single Moving RMS block, i.e., without using demux/mux. Did you try it out?

Just did, it does not seem exactly the same:

If I use only one block, the two outputs are the same, while I think we expect the bottom behaviour.


[MINOR] Use Debian as gravitino basic image ,otherwise lack of basic tools like 'wget','apt-get'

What changes were proposed in this pull request?
Use the linux distribution include basic tools like wget ,apt-get as basic image
The Debian linux distribution include basic tools like wget ,apt-get. While oracle linux use the YUM package manager, use yum command to install packages.
Why are the changes needed?
Gravitino docker used to build based on Debian, change to oracle linux is not consistent.
openjdk:17 ,it build from oraclelinux:8-slim
https://hub.docker.com/layers/library/openjdk/17/images/sha256-98f0304b3a3b7c12ce641177a99d1f3be56f532473a528fda38d53d519cafb13?context=explore
openjdk:17-jdk-buster, it build from debian:10, 10.12, buster, buster-20220418  https://hub.docker.com/layers/library/openjdk/17-jdk-buster/images/sha256-e462f39f589395ce928db22f3c8ea2ca83ade3f78a0227133b5ffebfa0289ab0?context=explore
Does this PR introduce any user-facing change?
N/A
How was this patch tested?
Run script on local:
./dev/docker/build-docker.sh --platform all --type gravitino --image datastrato/gravitino --tag 0.6.0-SNAPSHOT-268 --latest

@FANNG1  Can you help review it ? Thanks.

LGTM, @xunliu do you have time to review?


“messy code”

i follow this tutorial http://ispeakl33t.com/install-dnscrypt-centos/
Centos 5.5  64bit
/usr/local/sbin/dnscrypt-proxy

help me！ THX

That's not a code, it's a binary file. (Read: Compiled binary from the code.)

Where Will the configuration file？

Where can I find the configuration file？  THX

Centos has systemdicks, so use the included .socket and .unit files included with the source. Refer to this article if you want.

thanks

Or take a look at dnscrypt loader which configures everything for you.


SpikeTrains can be created with undefined length.

see https://github.com/NeuralEnsemble/elephant/issues/54

The correct behaviour I think would be to create a spike train of length 0.

I can not reproduce this. @rgerkin : is there still a problem?

@apdavison
I also can no longer reproduce the gist here, so it must be fixed, at least in my working copy of 0.4.0dev.


Yatin: Watch sportsdio.com

Yatin requests the watch of the watch_keyword sportsdio\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

sportsdio\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by double-beep in Charcoal HQ


is there a pytorch version?

No description provided.

Hi! Have you got the pytorch vision?

这是来自QQ邮箱的假期自动回复邮件。你好，邮件已收到，小谢会认真阅读哒~


added missing ASL licenses

added ASL license in files (*.java. *.drl) where it was missing
did mvn clean install -Dfull executing the tests and everything worked properly

http://github.com/droolsjbpm/guvnor/commit/df91efee2


Confused by the Timere documentation

I'm reading the documentation at
https://daypack-dev.github.io/timere/timere/Timere/index.html
(the current Timere head commit is 7bf138)
I am trying to represent a time interval in a calendar
(for example: "May 10th 2021, 10:00 to 11:30 in the Europe/Paris timezone")
Browsing the Timere documentation, it is not clear to me how this
should be represented.

I am not sure what a Timere.t is. The documentation says it is
"used to encode computation over time", what does that mean?
Is is a point in time, or a time interval, something else?
Timere.now : unit -> t suggests (to me) that it is a point in time.
Timere.union : t list -> t suggests (to me) that it is an interval,
or possibly a more freeform set of points in time (union of intervals, etc.)

Citing the documentation: "inter [] is equivalent to empty".
Shouldn't this be always instead, the neutral element of inter?

Plenty of functions are defined in terms of pattern before we have
seen pattern in the list. Weird.

After browsing plenty of stuff I don't care about (pattern,
weekdays, whatever), I find modules for Span, Duration, Timezone,
"Datetime and timestamps". Looks more like what I'm looking for.

After looking at the sub-modules, Span/Duration represents a vector in
time, and are equivalent (Duration is more user-friendly). They
could be grouped together in the toplevel documentation.

I'm probably looking for a pair of a point in time (Datetime.t ?) and
a Duration.t.

It is not obvious to me what a "Date_time" is; a word of explanation
in https://daypack-dev.github.io/timere/timere/Timere/Date_time/index.html
would be helpful.
I guess that Date_time represents a point in time specified by
hours/minutes/seconds/etc. within a given day/date.

Timezone looks descriptive enough.

The Timestamp documentation looks pretty dry. I don't know what
rfc3339 or iso8601 are, but seeing example usages may help me
understand which one I should use for the particular system I am
interoperating with (Caldav).

I find the Date_time documentation confusing:

link: https://daypack-dev.github.io/timere/timere/Timere/Date_time/index.html

it doesn't say what a Date_time.t is

tz_info is defined as a pair of Timezone and a Duration.t option.
What is the meaning of the Duration.t option? No idea, no documentation.

Data_time.t looks like a representation of a point in time.
(But then it maybe has some duration information?)

"Note that this may yield a ambiguous date time if the time zone has varying offsets, e.g. DST."
I don't understand what this means.

More feedback:

I wanted to use Duration but I need to use addition of time vectors, so I have to go through Span as it is the only module giving algebraic operations on span/durations. I wonder if splitting in two modules is the right approach, or if we should rather have a single module with two "views" of the same type, for creation and also observation of the span/duration values.

I was annoyed at the lack of way to convert 03 into  `Mar automatically. Later I found by chance that this function is available in the Utils value, but maybe the documentation of the month type should mention that Utils has helpers for them.

Thanks very much for the detailed feedback! I've been looking for a detailed review from potential user, so this is very nice.

I am not sure what a Timere.t is. The documentation says it is "used to encode computation over time", what does that mean?

I've updated the doc to read as follows
"
This is the core type of Timere used to encode computation over time, also called a "Timere object".
A Timere object is a lazily evaluated representation of computation built using constructors, where resolve forces the result of the computation (lazy sequence of intervals).
"
Hope this is better(?)

Citing the documentation: "inter [] is equivalent to empty". Shouldn't this be always instead, the neutral element of inter?

I think you're right (don't recall what the issue was that caused me to define it as empty). I've added the change and see if changes anything in the the testing pipeline.

Plenty of functions are defined in terms of pattern before we have seen pattern in the list. Weird.

Moved them to after pattern.

After browsing plenty of stuff I don't care about (pattern, weekdays, whatever), I find modules for Span, Duration, Timezone, "Datetime and timestamps". Looks more like what I'm looking for.

I've moved the "calendar" stuff to the top, and reasoning/scheduling to the bottom.

After looking at the sub-modules, Span/Duration represents a vector in
time, and are equivalent (Duration is more user-friendly). They
could be grouped together in the toplevel documentation.

Currently moved them to "Time vectors" section at top.

I'm probably looking for a pair of a point in time (Datetime.t ?) and
a Duration.t.

That is correct, though generally advised to go with a pair of Date_time.t or even better, timestamp.
let tz = Timere.Time_zone.make_exn "Europe/Paris" in
let x = Timere.Date_time.(
  make_exn ~year:2021 ~month:05 ~day:10 ~hour:10 ~minute:0 ~second:0 ()
  |> to_timestamp_single) in
let x = Timere.Date_time.(
  make_exn ~year:2021 ~month:05 ~day:11 ~hour:11 ~minute:30 ~second:0 ()
  |> to_timestamp_single)  in
(x, y)

Reason being distance between two time of day may not be constant due to DST depending on choice of hour etc.
There are better methods of constructions for this type of scheduling - I'll add them in the next comment.

It is not obvious to me what a "Date_time" is; a word of explanation
in https://daypack-dev.github.io/timere/timere/Timere/Date_time/index.html
would be helpful.
I guess that Date_time represents a point in time specified by
hours/minutes/seconds/etc. within a given day/date.

I've amended the description of Date_time.t to read as follows
"
This is the main date time type, and represents a point in the local time line with respect to the residing time zone. Conceptually a pair of "date" and "time of day".
A t always maps to at least one point on the UTC time line, and make fails if this is not the case. t may also map to two points on the UTC time line in the case of DST and without an unambiguous offset, however.
In the ambiguous case, functions which return _ local_result will yield an Ambiguous _ value, and Single _ otherwise.
ns may be >= 10^9 to represent leap second, but always remains < 2 * 10^9.
s is always >= 0 and < 60, even when second 60 is used during construction. In other words, second 60 is represented via ns field.
"

The Timestamp documentation looks pretty dry. I don't know what
rfc3339 or iso8601 are, but seeing example usages may help me
understand which one I should use for the particular system I am
interoperating with (Caldav).

I've added a small example, but I'm somewhat lost on what to add short of elaborating on the two individual standards.
For use in Caldav, I think you'll need to roll your own format string, e.g.
format = {year}{mon:0X}{day:0X} for Caldav DATE, or = "{year}{mon:0X}{day:0X}T{hour:0X}{min:0X}{sec:0X}" for DATE-TIME, in calls to Date_time.pp ~format () or Date_time.to_string ~format.

tz_info is defined as a pair of Timezone and a Duration.t option.
What is the meaning of the Duration.t option? No idea, no documentation.

I've repackaged it into a proper record type
type tz_info = {
  tz : Time_zone.t;
  offset : Duration.t option;
}

and description now reads as follows
"
Time zone information of date time
tz is the time zone tied.
offset, if specified, provides an unambiguous specification of which timestamp/point the date time maps to on the UTC time line
"

Data_time.t looks like a representation of a point in time.
(But then it maybe has some duration information?)

Sorry I don't follow. Why would it have duration information?

"Note that this may yield a ambiguous date time if the time zone has varying offsets, e.g. DST."
I don't understand what this means.

I've updated the text to read
"
Note that this may yield a ambiguous date time if the time zone has varying offsets,
causing a local date time to appear twice, e.g. countries with DST.
"

I wanted to use Duration but I need to use addition of time vectors, so I have to go through Span as it is the only module giving algebraic operations on span/durations. I wonder if splitting in two modules is the right approach, or if we should rather have a single module with two "views" of the same type, for creation and also observation of the span/duration values.

Good point - I did feel point of friction at places. Could you elaborate what the approach with "views" would look like?

I was annoyed at the lack of way to convert 03 into `Mar automatically. Later I found by chance that this function is available in the Utils value, but maybe the documentation of the month type should mention that Utils has helpers for them.

I've removed type month altogether - ~month is now just tied to numbers.
It seems that the type month was only for avoiding ambiguity when this library was using Unix.tm many moons ago. But now that is no longer the case, this type is kinda moot.

For the scheduling problem, the following should work, but doesn't when time zone is specified (still investigating why...)
let t = CCResult.get_exn @@ Timere_parse.timere "May 10th 2015 10:00 to 11am Europe/Paris" in
Timere.to_sexp_string t

yields
"(with_tz Europe/Paris (bounded_intervals whole (31622400 0) (points (pick ymdhms 2015 May 10 10 0 0)) (points (pick hms 11 0 0))))"

but resolve yields an empty sequence. Though this works fine with UTC time zone it seems (more debugging...).

Thanks very much for the detailed feedback! I've been looking for a detailed review from potential user, so this is very nice.

You are welcome. Sorry for this being a fairly unorganized dump, that
is correspongly not so convenient to discuss, but oh well.
I'm impressed with how reactive you have been in turning this
ill-structured feedback into concrete changes.

I am not sure what a Timere.t is. The documentation says it is "used to encode computation over time", what does that mean?

I've updated the doc to read as follows
"
This is the core type of Timere used to encode computation over time, also called a "Timere object".
A Timere object is a lazily evaluated representation of computation built using constructors, where resolve forces the result of the computation (lazy sequence of intervals).
"
Hope this is better(?)

This is an improvement, thanks!. But I have the impression that you
are putting implementation aspects (the fact that things are
lazily evaluated) before defining what it represents (unions of
intervals of points in time). I would maybe suggest the following:
"
This is the core type of Timere that represents sets of points in time, more precisely, unions of time intervals.
(For example: all Mondays of year 2000 at the UTC timezone.)
We call Timere.t values "timere object"; internally they are rich
expressions representing the time computations (union, intersection,
etc.), lazily forced into more low-level descriptions (lazy sequences
of intervals).
"
As a prospective user of Timere, I am less interested (than you and
other implementors are) in the description of how it is
implemented. Having a simple mental model in mind can still be useful
to understand potential performance implicitations, and in particular
"what can be done without blowing up completely".

I'm probably looking for a pair of a point in time (Datetime.t ?) and
a Duration.t.

That is correct, though generally advised to go with a pair of Date_time.t or even better, timestamp.
let tz = Timere.Time_zone.make_exn "Europe/Paris" in
let x = Timere.Date_time.(
  make_exn ~year:2021 ~month:05 ~day:10 ~hour:10 ~minute:0 ~second:0 ()
  |> to_timestamp_single) in
let x = Timere.Date_time.(
  make_exn ~year:2021 ~month:05 ~day:11 ~hour:11 ~minute:30 ~second:0 ()
  |> to_timestamp_single)  in
(x, y)

Reason being distance between two time of day may not be constant due to DST depending on choice of hour etc.

Actually in my specific case I am implementing a calendar for
a seminar (talks on a semi-regular basis); the talks start a given
point in time, and should last for 50 minutes plus 20 minutes question
and discussions. So storing the origin+vector makes perfect sense and
storing the second endpoint requires a computation. But of course both
representations are fine.

I've amended the description of Date_time.t to read as follows
"
This is the main date time type, and represents a point in the local time line with respect to the residing time zone. Conceptually a pair of "date" and "time of day".
A t always maps to at least one point on the UTC time line, and make fails if this is not the case. t may also map to two points on the UTC time line in the case of DST and without an unambiguous offset, however.
In the ambiguous case, functions which return _ local_result will yield an Ambiguous _ value, and Single _ otherwise.
ns may be >= 10^9 to represent leap second, but always remains < 2 * 10^9.
s is always >= 0 and < 60, even when second 60 is used during construction. In other words, second 60 is represented via ns field.
"

This is nice, thanks! As a non-expert in calendar matters, I am still a bit confused by this bit:

t may also map to two points on the UTC time line in the case of DST and without an unambiguous offset, however.

Actually I'm not sure what you are talking about. I would naively
assume that if I give you a date, a time-of-day and a timezone, this
is always unambiguous: even if the timezone is affected by Daylight
Saving Time (its offset relative to UTC changes over the year), we can
tell what the specific UTC offset is at this date. (Well okay, DST
rules can evolve over time so this becomes wrong in the future, but
let's say "within the current knowledge of timezone stuff".)
Or maybe you are talking about specifically what happens on the nights
during which daylight-saving-time starts and stops, there is some
ambiguity here about whether we are using pre-change or post-change
dates?
I would like to figure out if this DST ambiguity business is
something, as a user, I should understand well and be worried about
because it's going to bite me if I work with dates in a country using
DST, or if it's rather a pretty obscure corner case like leap seconds
stuff that I can ignore for my simple application, because the dates
I am working with are always during normal workdays and enver on
midnight between a Saturday and a Sunday.

tz_info is defined as a pair of Timezone and a Duration.t option.
What is the meaning of the Duration.t option? No idea, no documentation.

I've repackaged it into a proper record type
type tz_info = {
  tz : Time_zone.t;
  offset : Duration.t option;
}

and description now reads as follows
"
Time zone information of date time
tz is the time zone tied.
offset, if specified, provides an unambiguous specification of which timestamp/point the date time maps to on the UTC time line
"

It might be useful to point out in which direction the offset goes. If
I'm working with ours in UTC+1, should I pass +3600 or -3600?

Data_time.t looks like a representation of a point in time.
(But then it maybe has some duration information?)

Sorry I don't follow. Why would it have duration information?

I was confused by the Duration.t in the tz_info field, but now it's
clear what this is and not an issue anymore. Thanks!

"Note that this may yield a ambiguous date time if the time zone has varying offsets, e.g. DST."
I don't understand what this means.

I've updated the text to read
"
Note that this may yield a ambiguous date time if the time zone has varying offsets,
causing a local date time to appear twice, e.g. countries with DST.
"

As mentioned above, having slightly more explanation for people who
are not already calendar hackers could help. Looking at the
documentation of Timere (and Ptime before that) is the way I get to
learn about "how to deal with dates and timezones and stuff", I don't
have pre-existing knowledge of the intricacies here.

I wanted to use Duration but I need to use addition of time vectors, so I have to go through Span as it is the only module giving algebraic operations on span/durations. I wonder if splitting in two modules is the right approach, or if we should rather have a single module with two "views" of the same type, for creation and also observation of the span/duration values.

Good point - I did feel point of friction at places. Could you elaborate what the approach with "views" would look like?

I'll try to come up with a proposal later.

I was annoyed at the lack of way to convert 03 into `Mar automatically. Later I found by chance that this function is available in the Utils value, but maybe the documentation of the month type should mention that Utils has helpers for them.

I've removed type month altogether - ~month is now just tied to numbers.
It seems that the type month was only for avoiding ambiguity when this library was using Unix.tm many moons ago. But now that is no longer the case, this type is kinda moot.

For the record, I decided to just update my codebase to use the
polymorphic variant throughout (as I had no easy way to map numbers to
the variant in a helper function; well I was too lazy to define
it myself), and actually it's nice: I don't have to wonder whether I'm
using 0-11 or 1-12 encoding at the use sites anymore.
You know better, I would be mildly in favor of keeping this type
around, with conversion functions.

This is an improvement, thanks!. But I have the impression that you are putting implementation aspects (the fact that things are
lazily evaluated) before defining what it represents (unions of intervals of points in time). I would maybe suggest the following:
...
As a prospective user of Timere, I am less interested (than you and other implementors are) in the description of how it is implemented. Having a simple mental model in mind can still be useful to understand potential performance implicitations, and in particular "what can be done without blowing up completely".

Done. Largely copying your text.

Actually in my specific case I am implementing a calendar for a seminar (talks on a semi-regular basis); the talks start a given
point in time, and should last for 50 minutes plus 20 minutes question and discussions. So storing the origin+vector makes perfect sense and storing the second endpoint requires a computation. But of course both representations are fine.

Aha okay, then yep.

Actually I'm not sure what you are talking about. I would naively
assume that if I give you a date, a time-of-day and a timezone, this
is always unambiguous: even if the timezone is affected by Daylight
Saving Time (its offset relative to UTC changes over the year), we can
tell what the specific UTC offset is at this date. (Well okay, DST
rules can evolve over time so this becomes wrong in the future, but
let's say "within the current knowledge of timezone stuff".)
Or maybe you are talking about specifically what happens on the nights
during which daylight-saving-time starts and stops, there is some
ambiguity here about whether we are using pre-change or post-change
dates?
I would like to figure out if this DST ambiguity business is
something, as a user, I should understand well and be worried about
because it's going to bite me if I work with dates in a country using
DST, or if it's rather a pretty obscure corner case like leap seconds
stuff that I can ignore for my simple application, because the dates
I am working with are always during normal workdays and enver on
midnight between a Saturday and a Sunday.

Allow me to elaborate on this in the next comment.

It might be useful to point out in which direction the offset goes. If I'm working with ours in UTC+1, should I pass +3600 or -3600?

Good point. I've amended the documentation of Date_time.make_unambiguous to read as follows
"
Constructs a date time providing time zone offset in seconds, and optionally a time zone.
  Nanosecond used is the addition of [ns] and [frac * 10^9].

  If a time zone is provided, then [tz_offset] is checked against the time zone record,
  and returns [Error `Invalid_tz_info] if [tz_offset] is not a possible
  offset for the particular date time in said time zone.

  As an example, for "UTC+1", you would give a duration of positive 1 hour for `tz_offset`.

  Otherwise same leap second handling and error handling as [make].

"

As mentioned above, having slightly more explanation for people who are not already calendar hackers could help. Looking at the documentation of Timere (and Ptime before that) is the way I get to learn about "how to deal with dates and timezones and stuff", I don't have pre-existing knowledge of the intricacies here.

I'll note that Ptime's way of dealing with time zone is to ask user to provide a fixed time zone offset - this is not an accurate representation of what we normally mean by a "time zone", even with "Europe/Paris", sometimes the offset is UTC+2, sometimes it's UTC+1. Subsequently there is less confusion, at the cost of much difficulty moving between time zones or even between timestamps. Timere/Daypack-lib was originally using that, but it was then immensely difficult to state a scheduling constraint then from a user perspective, hence the current first-class(?) support of time zone.

For the record, I decided to just update my codebase to use the
polymorphic variant throughout (as I had no easy way to map numbers to
the variant in a helper function; well I was too lazy to define
it myself), and actually it's nice: I don't have to wonder whether I'm
using 0-11 or 1-12 encoding at the use sites anymore.
You know better, I would be mildly in favor of keeping this type
around, with conversion functions.

Oh oop, hm...should I add it back? Or just offer the previous bundle of variant type month utilities in Utils instead?

Actually I'm not sure what you are talking about. I would naively
assume that if I give you a date, a time-of-day and a timezone, this
is always unambiguous: even if the timezone is affected by Daylight
Saving Time (its offset relative to UTC changes over the year), we can
tell what the specific UTC offset is at this date. (Well okay, DST
rules can evolve over time so this becomes wrong in the future, but
let's say "within the current knowledge of timezone stuff".)

This is unfortunately incorrect. Take Europe/Paris as our example: DST ends at 3am 13th Oct 2021, at which point clocks switch back 1 hour, to 2am 13th Oct 2021. As a consequence the entirety of "2am to 3am (exclusive)" will appear twice.
Pick any intermediate point, say "2:30am 13th Oct 2021" and with only "Europe/Paris" as the sole time zone information, you necessarily have two possible interpretations. If you attach a fixed offset of either +1 or +2, then sure, you can have an unambiguous interpretation, but there is no general good rule on which interpretation is suitable for the user, hence we do not make up an answer here.
Some libraries (Crystal lang's stdlib time module, Pendulum from Python, Golang's stdlib) do implicit coercion when a timestamp interpretation is demanded (which interpretation is chosen is often undefined behaviour, however). They also do similar coercion with date times that cannot exist. DST started in Europe/Paris 28th March 2021 2am, at which point clocks jump forward to 3am, i.e. the entirety of "2am to 3am (exclusive) does not exist in the local time line. Timere (which borrows a fair bit of decisions from Rust's chrono package) refuses construction of such date time. Lbraries mentioned will coerce a non-existent "2:30am" into "3:30am" etc.
IMO this is highly problematic in terms of accuracy, and while might be tolerable for most date time handling, absolutely not fit for scheduling purposes.
If user wishes to mimic the coercion behaviour, they may use either min_of_local_result ormin_of_local_result (this incidentally reminded me I need to fix their signature...).
As an attempt at viewing this mathematically, we can consider the following illustration of their mapping, namely we can observe the lack of continuity of Europe/Paris time line (UTC time line is always continuous) when DST ends in Oct.
UTC          ----------------|----------------
                            1am

Europe/Paris ----------------|----------------
                          3am 2am
                         (+2) (+1)

Similarly, we  can observe a jump when DST started in March
UTC          ----------------|----------------
                            1am

Europe/Paris ----------------|----------------
                          2am 3am
                         (+1) (+2)

Or maybe you are talking about specifically what happens on the nights
during which daylight-saving-time starts and stops, there is some
ambiguity here about whether we are using pre-change or post-change
dates?
I would like to figure out if this DST ambiguity business is
something, as a user, I should understand well and be worried about
because it's going to bite me if I work with dates in a country using
DST, or if it's rather a pretty obscure corner case like leap seconds
stuff that I can ignore for my simple application, because the dates
I am working with are always during normal workdays and enver on
midnight between a Saturday and a Sunday.

If you are coordinating anything that has an international audience, then it is likely to bite you. For local only things, say if you're using Ptime, and you forget to use the right offset when converting to timestamp, you have just scheduled an appointment off by an hour. Which may or may not be critical.
As a user, Timere allows you to gloss over a lot of details (i.e. you don't have to figure out how the scheduler works with multiple time zones in a single timere object).
So you should be aware of the possibility (which Timere will explicitly bring up), but you don't need to understand it well (Timere offers exactly the possible interpretations when relevant).

On an unrelated note, I've fixed the issue : D
utop # let t = CCResult.get_exn @@ Timere_parse.timere "May 10th 2021 10:00 to 11:30am Europe/Paris" in
Fmt.pr "%a\n" (Timere.pp_intervals ~display_using_tz:(Timere.Time_zone.make_exn "Europe/Paris") ()) (CCResult.get_exn @@ Timere.resolve t);;
[2021 May 10 10:00:00 +02:00:00, 2021 May 10 11:30:00 +02:00:00)

The reason why I'm trying to switch from Ptime to TImere is precisely that I don't want to deal with DST shifts in my code by hardcoding specific offsets. So for me it's important to be able to understand what ambiguity cases arise (where I would need a specific offset, and there won't be one, and my program will behave slightly weirdly) and in which case they don't. The previous documentation didn't let me understand that the issue was during an hour around each dayling-saving-time change, which is perfectly fine for my needs.
The explanation in https://github.com/daypack-dev/timere/issues/25#issuecomment-829188579 is excellent, thanks. If there is a document that already explains that, mentioning it in the documentation could be nice. Otherwise rephrasing it and including it in the doc, or just pointing to it from the doc, could help. But maybe having a more concise summary first would also help, I'll see if I can suggest something.

The reason why I'm trying to switch from Ptime to TImere is precisely that I don't want to deal with DST shifts in my code by hardcoding specific offsets. So for me it's important to be able to understand what ambiguity cases arise (where I would need a specific offset, and there won't be one, and my program will behave slightly weirdly) and in which case they don't. The previous documentation didn't let me understand that the issue was during an hour around each dayling-saving-time change, which is perfectly fine for my needs.

Out of curiosity, where did you hear about Timere?

The explanation in #25 (comment) is excellent, thanks. If there is a document that already explains that, mentioning it in the documentation could be nice. Otherwise rephrasing it and including it in the doc, or just pointing to it from the doc, could help. But maybe having a more concise summary first would also help, I'll see if I can suggest something.

Awesome! I'll add it to the documentation in some way, and yep do let me know if you come up with something.
Incidentally we have a scheduling example in case it's useful: https://github.com/daypack-dev/timere/tree/main/examples#querying-across-dst-boundary

Out of curiosity, where did you hear about Timere?

I learned about it (from an obscure compiler issue about compilation blowup and) from your 0.1.3 announce on Discuss.

Incidentally we have a scheduling example in case it's useful: https://github.com/daypack-dev/timere/tree/main/examples#querying-across-dst-boundary

Thanks! My use-case is to programmatically create single events, so not directly useful for me, but it is a nice example. Could it maybe also be included in the generated documentation?

let me know if you come up with something.

Maybe something like this, as the introduction of the module?

The type Date_time.t is the main date-time type, it represents
a point in a local time line with respect to the residing time
zone. Conceptually a pair of "date" and "time of day".
Note: This module uses Ptime (TODO link to Ptime) underneath, and
carries similar limitation of expressible range of date
times (basically, years from 0 to 9999 only). The actual range is
slightly more limited in Timere due to time zones.
Ambiguous date-times: for timezones that use Daylight Saving
Time (DST), a date-time may be ambiguous if it falls within one
hour around the DST change. For example, in 2012 DST ended in
most of Europe at 3am 13th Oct 2021, switching clocks back to 2am
on the same day. As a consequence the interval from 2am to
3am (exclusive) appears twice in the time line.
Such a datatime can be disambiguated by providing an explicit
time zone offset. For example, if a particular timezone is at
UTC+1 or UTC+2 depending on whether DST is in effect, specifying
a disambiguation offset of 1 hour in the {!tzinfo} data will use
UTC+1 in the ambiguous cases.
This disambiguation offset is optional, to Timere can represent
both ambiguous and unambiguous datetimes. Ambiguity will show up
when converting to an absolute timestamp, as the  `Ambiguous
constructor in the {!local_result} type.

Note: it is still not completely clear to me if the offset field of tzinfo is only used in the case of ambiguous local date-times (failing if it not one of the two possible offsets giving the two possible absolute times), or if it used for all local date-times, with a failure for date-times where it is not the current offset (or, in ambiguous cases, one of the current offsets). I think it is the former (the latter sounds rigid and inconvenient), but the current doc is not clear about this.

Thanks! My use-case is to programmatically create single events, so not directly useful for me, but it is a nice example. Could it maybe also be included in the generated documentation?

Good point.

Note: it is still not completely clear to me if the offset field of tzinfo is only used in the case of ambiguous local date-times (failing if it not one of the two possible offsets giving the two possible absolute times), or if it used for all local date-times, with a failure for date-times where it is not the current offset (or, in ambiguous cases, one of the current offsets). I think it is the former (the latter sounds rigid and inconvenient), but the current doc is not clear about this.

Okay yep, I should make when would yield which combination of tz_info more explicit.
Right now

It is only set in make if it is possible to deduce (provided time zone and date time happens to not be ambiguous) an unambiguous offset. It is None if date time in the time zone is ambiguous.
It is always set in make_unambiguous, where user is demanded an offset.

Re month type:
Since reintroducing it back into the original places means a lot of friction that was removed has to be reintroduced as well, I opted to moving the type and corresponding helper functions to Timere.Utils for now.

Since reintroducing it back into the original places means a lot of friction that was removed has to be reintroduced as well, I opted to moving the type and corresponding helper functions to Timere.Utils for now.

Yes, I think this is fine! (And also not having it is fine.) Thanks again for the prompt changes.

I believe that the issues here have been addressed, so closing. Thanks again for being very reactive.

Thanks very much again for the feedback! Timedesc 0.1.0 will be pushed to opam shortly.


 Similar to this case https://github.com/epam/mriviewer/issues/126
Also in the demo aviable in this repo I cant load a .dcm file

@AdolfoBanchio Thanks for opening an issue.
We have released version 2.0 of MRI viewer. Could you try to reproduce please?
If you face any problems please open new issue with details.
Thank you

For me I just had to use node 16, using nvm, to get it to work. On 18 and 20 it does not work, including the new 2.0 release. I think it should be made clear in the readme that this requires node 16.


Ask user to confirm info before creating Install

Closes https://github.com/nycmeshnet/meshforms/issues/56

Idea: Instead of logging PII, add some marker to the join form log expressing that there was a problem. That would require appending to an existing S3 object in meshforms, since it would save the submission immediately upon entry.

Yeah i think i already thought of this but http code

I think now all's I gotta do is update Meshforms. Having just spent 30+ hours learning more React, I have i d e a s.

Maybe I could include the PII in the Notes of the created user as well...?

Maybe Django is formatting it after the fact? IDK I need to do some more testing.

>>> print(phonenumbers.format_number(phonenumbers.parse("+1<PHONE_NUMBER>", "US"), phonenumbers.PhoneNumberFormat.INTERNATIONAL))
+1<PHONE_NUMBER>
>>> print(phonenumbers.format_number(phonenumbers.parse("+1614-307-4056", "US"), phonenumbers.PhoneNumberFormat.INTERNATIONAL))
+1<PHONE_NUMBER>

yolo'ing it with approval to do so from @Andrew-Dickinson


Save ParaStell Class Objects

It could be nice to provide the option to save ParaStell class objects (i.e., Stellarator, InVesselBuild, MagnetSet, and SourceMesh) to a file that can later be loaded into a separate script. This way, users could reference useful data we store, such as volume IDs, source mesh strengths, etc. This may be possible via the pickle module (see this example).

I've had issues with pickle and netCDF4 objects in the past - some of the multithreading approaches I tried for the nwl used pickle to pass off copies to each thread and that failed, but not sure if that is specific to how the that multithreading module uses it or is just an issue with netCDF4 objects in general.


Working with databases

do we want to recommend a certain lib (like jdbi) or would this only cover jdbc?


[BEAM-10869] Make WriteToPubsub output serialized PubsubMessage proto bytes when using runner v2

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Kindly pinging : )

r: @chamikaramj

Run Python PreCommit

retest all please

Run Java PreCommit

Run Java_Examples_Dataflow PreCommit

Run Python PreCommit

Run Python2_PVR_Flink PreCommit

Run Java PreCommit

Run JavaPortabilityApiJava11 PreCommit

Run Python PreCommit

Run PythonDocker PreCommit

Based upon the python precommit results, this PR is blocked until the updated Dataflow runner v2 gets released containing your changes.

Run Java PreCommit

Run Python_PVR_Flink PreCommit

Run Python PreCommit

Run Python PreCommit

Run Python PreCommit

The test is still pulling  gcr.io/cloud-dataflow/v1beta3/unified-harness:20200615-rc00, not the latest released one.

Run Python PreCommit

LGTM. Thanks.

Python tests / Python Unit Tests (windows-latest, 3.6, py36) failure is not related.

I'm going to merge this PR now. Thanks for all your help!


Timepicker

Adds timepicker addon if showTime: true in your opts.

Since this is kind of a different UI element, maybe a uiDatetime directive would be more appropriate? Certainly seems more declarative.

And then have the directives call a private function with effectively a showTime boolean (false for the orginal, true for the new directive) or some other callback function with the difference? In order to reuse all the code I'm thinking.

Any response to my questions above? I would like to make this pull request happen. Cheers.

@crowmagnumb I'm a bit torn here and tend to agree with @nateabele here as this directive is just intended for making the datepicker work and keeps it simpler to only have to support jquery datepicker as the dependency.

I would expect that there are more than just the activation of the jQuery plugin (getting and setting dates from model updates as well as tracking the various events) so for now I think it best to keep the timepicker separate.


Source maps not working

This is due to an issue in systemjs, but it will get resolved once the compiler supports the system module format and inline source maps.

:+1: Thanks for all your work!

These are now working in version 2.0


Table plugin resize not working

Describe the bug
Table plugin resize not working
To Reproduce
Steps to reproduce the behavior:

set table and set column width
check on other page by v-html
the column still same size

Is that how you use it ? new Table({ resizable: true })


BUG: Rancher 2.5.6 AmazonEC - The parameter iops is not supported for gp2 volumes.

Error creating machine: Error in driver during machine creation: Error launching instance: InvalidParameterCombination: The parameter iops is not supported for gp2 volumes.

Error creating machine: Error in driver during machine creation: Error request spot instance: InvalidParameterCombination: The parameter iops is not supported for gp2 volumes.

I use Custom AMI (us-west-2a: ami-0c0b365b3bc54fbb0) with GP3 storage, before 2.5.5 everything working like a charm, with 2.5.6 i see above error.
Rancher 2.5.5 always just ignore volume type and deploy gp2.
#22898

This only appears to happen if you have a gp3 disk specified in the AMI. If it's gp2, it builds out fine


CnC file not created: /dev/shm/aeron-root/cnc.dat

Trying to run sample program and it is retuning with error messages.
./basic_subscriber -c aeron:udp?endpoint=<IP_ADDRESS>:40456|interface=<IP_ADDRESS>
aeron_init: (-1000) unknown error code
[aeron_client_connect_to_driver, aeronc.c:54] CnC file not created: /dev/shm/aeron-root/cnc.dat

You need to be running a media driver.

Yes.  I did run media driver.
ps -ef | grep aeron
root     31461 31308  1 Sep19 pts/0    00:23:33 ./aeronmd.
But
./AeronStat
(-1000) unknown error code
[aeron_cnc_init, aeron_cnc.c:72] Timed out waiting for CnC file to become available after 1000ms

The media driver and the app needs to be the same USER. Or you have to specify the Aeron directory. Also, the directory needs to be accessible by both, etc.
If you need assistance, we offer support.

USER is root to start all the apps.
Directory permission is 755.
How can I get support?

How can I get support?

Email<EMAIL_ADDRESS>


Symbols at the same geolocation

Bug:
Two or more symbol layers when placed at the same location perform as expected upto a certain zoom point, as shown in the first screenshot. However, when zoomed in to a certain extent, these symbols would superimpose, and just one point is visible and can't be differentiated, as shown in the second screenshot.

Expectation:
When two or more points are at the same geolocation (or within a certain radius say 5px - need to add this as a prop), they should stay spiderfied and always be shown as leaves. (same as screenshot 1)

Update: Figured this can be configured by providing clusterMaxZoom to the Source. Closing this issue.


doc: Remove some items from todo.txt

MS-Windows: did path modifier :p:8 stop working?  #8600

Fixed in 8.2.4535.

Add "unicode true" to NSIS installer.  Doesn't work with Windows 95, which we
no longer support.

Added in 8.1.0616.

":cd C:\Windows\System32\drivers\etc*" does not work, even though the
directory exists. (Sergio Gallelli, 2013 Dec 29)

I think this can happen when 32-bit Vim is used on 64-bit Windows. C:\Windows\System32 will be redirected to C:\Windows\SysWOW64, and it doesn't have the drivers directory.
We could make this work by calling Wow64DisableWow64FsRedirection(), but I don't think it is needed.
https://learn.microsoft.com/en-us/windows/win32/api/wow64apiset/nf-wow64apiset-wow64disablewow64fsredirection
32-bit applications can read the 64-bit system directory by accessing C:\Windows\Sysnative, but this is read-only.

8   Win32 GUI: With maximized window, ":set go-=r" doesn't use the space that
comes available. (Poucet)  It works OK on Win 98 but doesn't work on Win
NT 4.0.  Leaves a grey area where the scrollbar was.  ":set go+=r" also
doesn't work properly.

Doesn't reproduce on Windows 10.

Win32 GUI: mouse wheel always scrolls rightmost window.  The events arrive
in Vim as if the rightmost scrollbar was used.

'scrollfocus' was added in 8.1.2257.

7   GvimExt: when there are several existing Vims, move the list to a submenu.
(Mike McCollister)

Fixed in 8.1.0492.

You could perhaps remove this item as well
https://github.com/vim/vim/blob/5ceb8157bc4608eeff4b7453da31ebe65f08a862/runtime/doc/todo.txt#L1176-L1177
I believe the relevant patch would be 8.2.3255

I'll include it, thanks.


'JobExecutionContext.getRecoveringTriggerKey()' is returning TriggerKey with 'name' and 'group' interchanged.'

When a job is recovered, we can get 'TriggerKey' of an originally failed job using method 'getRecoveringTriggerKey()'
Seems like there is the small goof up in an implementation of this method.
In class org.quartz.impl.JobExecutionContextImpl.java
inside method getRecoveringTriggerKey()
paramters passed while creating 'TriggerKey(String TriggerName, String TriggerGroup)' object are interchanged.
Error found in quartz java library 'Quartz 2.2.3'

Closing as dup and fixed in #193


Temperature reading for T265 internal processor ?

Required Info

Camera Model
{T265}

Firmware Version
(/)

Operating System & Version
Linux (Ubuntu 16.04 & Dietpi 6)

Kernel Version (Linux Only)
(4.15.0-65-generic (ubuntu) & 4.14.52 (dietpi)

Platform
PC & NanoPi K1Plus

SDK Version
{ 2.. }

Language
{C++ }

Segment
{others}

Issue Description
Hello,
Is there any way to get a reading of the temperature of the T265 internal processor ? Could the temperature have an impact on the precision of the pose values ?

Hi @HndsmJohn
Yes there is a way to get ASIC temperature readout via the SDK.  I've included a link to the tm-device.cpp source code and it has information there for you to obtain.
https://github.com/IntelRealSense/librealsense/blob/9f99fa9a509555f85bffc15ce27531aaa6db6f7e/src/tm2/tm-device.cpp
Also you can see the temp readouts via the RealSense Viewer as it is also an example of getting the temp readouts from the sensors.
Let me know if there is anything else needed on this thread.
Thanks


Enhancements in the scalafix rule and tests

fix import of jawn-ast in the benchmarks/memory module which causes sbt errors when building project or importing it on IDE. jawn-ast is not available for Scala 2.13 (default)
add rewrites for more collection types. Also, fix imports of types imported via full package name rather than via scala.* or scala.Predef (e.g.: import scala.collection.immutable.Set, import scala.collection.Iterable).
remove global imports of scala.collection.* types to avoid clashes with counterparts in strawman.collection.*
add more tests and move the input/output objects originally in Collectionstrawman_v0 into separate files so that the rewrites for each collection type can be tested in isolation. This avoids that a symbol replacement for one collection type accidentally fixes the import for another collection type which is not correctly handled by the scalafix rule.

Hey @marcelocenerine, thanks a lot for helping on this :) However I was thinking that we should wait for the new collections to be part of the scala namespace (instead of the current strawman namespace) before putting too much effort in the migration rules because it seems that 80% of the work is about re-arranging the imports to target strawman.… instead of scala.….
What do you think?

@julienrf, that's true :D. Most of the work is to re-arrange the imports. Let's wait then. I'm gonna close this PR


Maven Wrapper v3.1.0 with Maven v3.8.4

Now the Takari Maven Wrapper has been adopted by Apache Maven, I'm submitted again.
This makes cicd simpler so now the cicd process can be used to check the latest maven works.
Each project does need to be individually managed but also if projects require a specific maven version, it can be pinned.

My preference is to not clutter each component with this noise, it's redundant.

@garydgregory i agree it could be considered clutter. If all projects are kept active current it's never an issue.
From experience I'm coming from working with dead or hibernated projects, when moving company/job/team/project and having to kick start something building. It use to work on the cicd server, but someone updated that to a newer maven version or java version so the project i'm working doesn't work anymore. So 1st things I now always setup is maven wrapper (takari before it was merge) and enforcer, so the project itself knows was it was last configured to build under.

I'm still -1 for now. We have GitHub Actions builds, we used to also have Jenkins builds, but I'm not sure we need those unless we want to push SNAPSHOTS from within Apache. Forcing whatever pile of scripts and files in the root of the project makes a bigger mess, and what makes it worse and is confusing is then looking at whatever files are used to define CI builds. Fortunately, I recently dropped most Travis CI config files, so that leaves us with GitHub and Jenkins (which is defined elsewhere)

WIll close my maven wrapper pr's for apache commons. Giving up trying to advocate the benefits.


Old Gem (removed? / changed?) occupying "Empty Socket" stopping new gem from filling it

Noticed this on a set of leggings, images below show the context

Anyway to fix this without destroying the other gems (Vial of Searing Explusion)

As you can see, a "fake" gem is occupying the Empty socket but on other tools it still shows as blank (These do work with gems)

Fixed via side effect of the fix for #984


Convert mmdet into open-world?

Hello, dear authors!
Is it possible to convert mmdet into an open world object detector?(like 《Towards Open World Object Detection》or 《Learning Open-World Object Proposals without Learning to Classify》)
Thank you！

I think that mmdet can support open-world object detection, but we don't have plans to support it recently. PRs are welcome to support open-world detector

Thank you!