Unexpected token ILLEGAL

ERROR in ./client/styles/style.scss
Module build failed: ModuleParseError: Module parse failed: G:\work\cinema\client\styles\style.scss Line 1: Unexpected t
oken ILLEGAL
You may need an appropriate loader to handle this file type.
| @font-face {
|       font-family: 'PT Sans';
|       font-weight: normal;

I was having this error when in webpack configuration I had loaders: [ExtractTextPlugin.extract(...)] and didn't have this error when it was temporarily changed to loader: ExtractTextPlugin.extract(...).
Seems to be a bug: loaders[] and loader should be interchangeable.

I got the same error. Please, fix this!

same here!

Had the same problem.
Was using the new
module: {
   rules: {
      {
         test: ...,
         use: ...
      }
   }
}

syntax from webpack 2 instead of
module: {
   loaders: {
      {
         test: ...,
         loader: ...
      }
   }
}

So I had, inside my rules:
{
    test: /\.css$/,
    use: ExtractTextPlugin.extract({fallbackLoader: 'style-loader', loader: 'css-loader'})
}

I changed use to loader and now I don't get the unexpected tokens
{
    test: /\.css$/,
    loader: ExtractTextPlugin.extract({fallbackLoader: 'style-loader', loader: 'css-loader'})
}

Thanks @kevindqc! Changing use to loader worked for me.

many thanks @kevindqc! Changing from use to loader fixed my CI.
is it a bug?

use is supported since rc0. In fact, using loader is illegal now.


Some docs fixes

Adapt to the Documenter.jl breaking release 1.0.0. This made strict checks on my default, which seems to be fine for most of the checks, except :missing_docs, which I manually excluded (that tests that every single docstring is in the public docs, which seems a bit excessive).

Remove index.md, since it is auto-generated and the current file is outdated

Nice work, LGTM!


time.time() fails on slim

Copied from https://bugs.python.org/issue45960:
Given a docker container on raspbian 10.11
based on bullseye:
docker run --rm -it --entrypoint sh python:3.10-slim
time.time() fails with error
# python
Python 3.10.0 (default, Nov 18 2021, 00:56:34) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
PermissionError: [Errno 1] Operation not permitted

based on buster:
docker run --rm -it --entrypoint sh python:3.10-slim-buster
python
Python 3.10.0 (default, Nov 18 2021, 02:00:41) [GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time()
1638433441.9555993
>>> exit()

works as expected

This is likely related to https://github.com/moby/moby/issues/40734 -- you'll need to update Docker and libseccomp on your host.  (See also #634)


[enhancement] Package as an NPM module

Would be nice if Sketch was on NPM. Just needs a package.json.
There's already a 'sketch' on NPM... I guess package name could be 'sketch-js'.
I can send a PR if you like?

https://github.com/soulwire/sketch.js/pull/70

Thanks for adding that @JasonStorey


Reorganization of Relation

This thread relates to the reorganization of Relation to make clear that the items under the Relation subtree are strictly binary operations. This issue is related to issue #269, issue #280, and issue #281.

Changed Left-side to Left-side-of  and Right-side to Right-side-of to make clear that these are to always be tagged as (A, (Left-side-of, B))  to mean that A is on the left side of B as to designate a left-hand.

Modified the Ordering-relation section to clarify that these are actually binary operations.
Example:   The tag First-item is now First-item-of and the description is:

(A (First-item-of B)) means that A is the first item of B. Here B could be anything that has a linear order such as a course, process, or list.

How do we tag "pressing left button" in this case? Should we allow a dummy node in the schema?
I'm noticing there's "Left-of" and "Left-side-of" right now in 8.0.0-beta.5. Same for "Right-of" and "Right-side-of"

Rename Data-type to Data-value-type  to make more clear.  (Data-type occurs elsewhere in OWL to mean something else.)
Move Quantitative-relation/Estimated   to  Data-value-type/Estimated-value
Move Quantitative-relation/Exact to Data-value-type/Exact-value
Remove Quantitative-relation/Approximated  because this term is to close to Estimated
Remove Quantitative-relation as it no longer has children.
Rename Data-value-type/Categorical-type to be Data-value-type/Categorical-value  as this fits better with what its children are called.

As per meeting 7/29/2021  @dungscout96 @smakeig @VisLab:
Eliminate Relation/Ordering-relation
The ordering relations are being replaced by more precise ordering with streams.  That is we now use:
(Event-stream/Faces, Repetition-number/1) to designate the first item in the event stream named Faces.
The expectation is that each event that is a face presentation would be annotated by (Member-of, Event-stream/Faces), This will allow automated tools to automatically identify which events correspond to faces.  Events can be members of multiple streams.

As per meeting 7/29/2021  @dungscout96 @smakeig @VisLab:
Eliminate the level Spatiotemporal-relation by moving Positional-relation and Temporal-relation up a level.
Also rename Positional-relation to be Spatial-relation since some members are spatial not positional (such as Boundary-of).

Eliminate Relation/Ordering-relation
The ordering relations are being replaced by more precise ordering with streams. That is we now use:
(Event-stream/Faces, Repetition-number/1) to designate the first item in the event stream named Faces.
The expectation is that each event that is a face presentation would be annotated by (Member-of, Event-stream/Faces), This will allow automated tools to automatically identify which events correspond to faces. Events can be members of multiple streams.

Good -  then is there a place to define the 'Faces' stream with a Description ?
However, the term 'Repetition-number' doesn't imply  index in the stream series ... better to use  'Stream-index' (when needed). ?
In the H&W case where repetition (of a single face image) is important, should we want to declare each new image a new stream?? For one, inventing labels for them all would be bothersome and likely the results confusing ... Better to use a tag 'Repetition-of' taking an event number --- But are there event numbers??  So, I'd suggest 'Repeat-presentation', # where # = 0 meaning this is not a repeat of a previous presentation, # = 1 means 1st repetition, etc...

How do we tag "pressing left button" in this case? Should we allow a dummy node in the schema?

Dummy mode = ?

I'm noticing there's "Left-of" and "Left-side-of" right now in 8.0.0-beta.5. Same for "Right-of" and "Right-side-of"

Were the intended meanings "To-left-of"  and "Left-side-of"  respectively?
I'm wondering if each Item introduced should not receive an index number. ... ?

Modified the Ordering-relation section to clarify that these are actually binary operations.
Example: The tag First-item is now First-item-of and the description is:

(A (First-item-of B)) means that A is the first item of B. Here B could be anything that has a linear order such as a course, process, or list.

Changed Left-side to Left-side-of and Right-side to Right-side-of to make clear that these are to always be tagged as (A, (Left-side-of, B)) to mean that A is on the left side of B as to designate a left-hand.

Yes, but how is B described ... as an already-identified item or agent?   If so, having some index number scheme for items and for agents should be a good idea...    For example, (A, (Left-side-of, Tree)) ... Does this mean the tree in the picture that was already tagged, or some other (new) tree?? ...

Yes Left-of should be To-left-of.   I'll make the change.
The index number and the Repeat seem reasonable, but I have questions on
the details.  Let's discuss this at Monday's meeting.
On Fri, Jul 30, 2021 at 12:12 PM smakeig @.***> wrote:

How do we tag "pressing left button" in this case? Should we allow a dummy
node in the schema?
Dummy mode = ?
I'm noticing there's "Left-of" and "Left-side-of" right now in
8.0.0-beta.5. Same for "Right-of" and "Right-side-of"
Were the intended meanings "To-left-of" and "Left-side-of" respectively?
I'm wondering if each Item introduced should not receive an index number.
... ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hed-standard/hed-specification/issues/284#issuecomment-890035146,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJCJOSVHGQ5Z7PPZXABCN3T2LMQBANCNFSM5BGMG3NA
.

Thinking about a more general solution for the event stream specification problem (syntax and naming used below is only for demonstration purposes. They might not be precise and are not final syntax proposal):

When specifying event stream, user can associate it with a definition. e.g. (Event-stream/Face-presentation, Def/Show-face)
When assembling HED annotations, HED tools can automatically put in "Event-stream-index/#" to each event in the stream containing the definition, automatically incrementing index number. Onset/Offset mechanism can be used to indicate start and stop of the stream, as well as reset. If need to, we can consider automatically numbering different instantiations of the same event stream type.
So the 12th show-face event will include "(Event-stream/Face-presentation, Event-stream-index/12)" in its HED string. An event can belong to multiple streams, which means that it can have multiple "(Event-stream/#, Event-stream-index/#)" tag groups. This provides enough evidence for derived annotation, which to be explained next:
We can write functions that sub-select events within a stream based on HED tags. For example, getIdenticalEvents(event_stream, HED_tag) --> getIdenticalEvents(Face-presentation, Image-path) can pull out all sets of events that belong to the Face-presentation stream that has identical image file paths. Image-path/# is part of the HED string for each event and uniquely identifies the face images. This opens up the possibility of annotating other kinds of combination for events within a stream, using other HED tags.
The result of function above can then be used as indices to pass to the next set of functions, which add HED tags to the selected events using specific criteria. For example, autoincrement(event_indices, HED_prefix) --> autoincrement(identical_face_presentation_events, Repetition-number/#) will add repetition number automatically in incrementing order for the events in the set. Or pariwiseStreamIndexDistance(event_indices, HED_prefix) --> pairwiseStreamIndexDistance(identical_face_presentation_events, Occurrence-interval/#) will add interval between each pair of the events in the set using Event-stream-index/# in their HED strings.
All these functions called should be documented, either in a designated file (e.g. hed_derived_annotation.m) or automatically (similarly to eeglab history mechanism). In this manner, we have full governance and integrity check for derived annotations.

This line of thinking suggests that annotations entailing relationships between events should be done via documented HED-enabled functions, instead of direct tagging. Direct annotation should only be done for stand-alone, unambiguous aspects of events (e.g. description of what was presented on the screen). This takes away the burden of handling complex logic from the HED syntax, while allowing governance of how derived annotations were made.
Just some rough ideas...

Good thinking, Dung -
Yes, Event-stream labels are useful for incorporating the exp design logic
in the annotation.  They are useful in building analysis scripts - but may
rarely be needed to document the experiment Event details....
On Mon, Aug 2, 2021 at 2:31 PM Dung Truong @.***> wrote:

Thinking about a more general solution for the event stream specification
problem (syntax and naming used below is only for demonstration purposes.
They might not be precise and are not final syntax proposal):

When specifying event stream, user can associate it with a
definition. e.g. (Event-stream/Face-presentation, Def/Show-face)
When assembling HED annotations, HED tools can automatically put in
"Event-stream-index/#" to each event in the stream containing the
definition, automatically incrementing index number. Onset/Offset mechanism
can be used to indicate start and stop of the stream, as well as reset. If
need to, we can consider automatically numbering different instantiations
of the same event stream type.
So the 12th show-face event will include
"(Event-stream/Face-presentation, Event-stream-index/12)" in its HED
string. An event can belong to multiple streams, which means that it can
have multiple "(Event-stream/#, Event-stream-index/#)" tag groups. This
provides enough evidence for derived annotation, which to be explained next:
We can write functions that sub-select events within a stream based
on HED tags. For example, getIdenticalEvents(event_stream, HED_tag)
--> getIdenticalEvents(Face-presentation, Image-path) can pull out
all sets of events that belong to the Face-presentation stream that has
identical image file paths. Image-path/# is part of the HED string for each
event and uniquely identifies the face images. This opens up the
possibility of annotating other kinds of combination for events within a
stream, using other HED tags.
The result of function above can then be used as indices to pass to
the next set of functions, which add HED tags to the selected events using
specific criteria. For example, autoincrement(event_indices,
HED_prefix) --> autoincrement(identical_face_presentation_events,
Repetition-number/#) will add repetition number automatically in
incrementing order for the events in the set. Or pariwiseStreamIndexDistance(event_indices,
HED_prefix) -->
pairwiseStreamIndexDistance(identical_face_presentation_events,
Occurrence-interval/#) will add interval between each pair of the
events in the set using Event-stream-index/# in their HED strings.
All these functions called should be documented, either in a
designated file (e.g. hed_derived_annotation.m) or automatically (similarly
to eeglab history mechanism). In this manner, we have full governance and
integrity check for derived annotations.

This line of thinking suggests that annotations entailing relationships
between events should be done via documented HED-enabled functions, instead
of direct tagging. Direct annotation should only be done for stand-alone,
unambiguous aspects of events (e.g. description of what was presented on
the screen). This takes away the burden of handling complex logic from the
HED syntax, while allowing governance of how derived annotations were made.
Just some rough ideas...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hed-2Dstandard_hed-2Dspecification_issues_284-23issuecomment-2D891242282&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=Q6VwIvvIaQjVQl825JdZjGdOAgpgrYjKKT5f7HuH8Ck&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AKN2SFT7NVAGM2B4LX65RBDT23QBXANCNFSM5BGMG3NA&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=e6ZuKY4DFedbxUmXUIWTl_P6oWRns7YapN91u8IVgM4&e=
.
Triage notifications on the go with GitHub Mobile for iOS
https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.apple.com_app_apple-2Dstore_id1477376905-3Fct-3Dnotification-2Demail-26mt-3D8-26pt-3D524675&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=N3O8xvsf6cSWvwZzIBxObf5qF6Vp7158jYdMQKMBWG8&e=
or Android
https://urldefense.proofpoint.com/v2/url?u=https-3A__play.google.com_store_apps_details-3Fid-3Dcom.github.android-26utm-5Fcampaign-3Dnotification-2Demail&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=1Fb1za6oJdsOkwvID4TH16fb4h00buY0uTni7tQNKhI&e=
.

--
Scott Makeig, Research Scientist and Director, Swartz Center for
Computational Neuroscience, Institute for Neural Computation, University of
California San Diego, La Jolla CA 92093-0559, http://sccn.ucsd.edu/~scott

This was debated extensively at meeting of 8/2/2021 (@smakeig @dungscout96 @VisLab). It was decided to not do major additions of Event-stream support although the concept of Event-stream will be supported.  The concept of Parameter was reintroduced to be used to annotate experiment-specific concepts like repetition.
Property

Informational-property

Parameter

Parameter-label
Parameter-value

@makeig @dungscout96
I have been working through the write-up in the specification and it solves some problems but not all of our problems.  I think we should encourage people to use Parameter rather than extending tags for things that are specific to experiments. I still need think we need to be able to express the interval between something and the count of something in the HED hierarchy.
Example:  Use Parameter to express the fact that this is the second time that this particular face has appeared and that it last appeared 15 faces ago:

(Parameter-label/Count-of-this-face, Parameter-value/2)
(Parameter-label/Face-count-since-this-face-appeared-last, Parameter-value/15)

This is all well and good.  However, Parameter-value provides no information about the kind of value and cannot have units.
We have Temporal-value/Time-value and Temporal-value/Time-interval for time measures that have time units and are numeric. I think we should have two corresponding things for counts: Quantitative-value/Count and  Quantitative-value/Count-interval .  Thus, I think the following is preferred so that tools know the values are numeric and integers.

(Parameter-label/Count-of-this-face, Count/2)
(Parameter-label/Face-count-since-this-face-appeared-last, Count-interval/15)

We might also put additional information in:

(Parameter-label/Count-of-this-face, Count/2, (Face, Image))
(Parameter-label/Face-count-since-this-face-appeared-last, Count-interval/15, (Face, Image))

Kay/Dung -
I was thinking while waking up this morning that a large 'missing piece' in current HED-3G is the task design ... and the most essential elements of it are not difficult to begin on - namely, the issue of imperative stimuli:
For the oddball:
button_press_stream, '(...)'
stream tone_stream
stream standard_stream '(...)'
stream target_stream, '(..., (imperative, button_press_stream)'
and
define target, '(..., target_stream)'
define standard, '(..., standard_stream)'
This sets up the imperative,   target --> button_press
A second thought
trial specification:       Again, for ease of analysis
trial standard_trial, '(fixation_cross, (delay, 500)', tone_stream, button_press_stream, (delay, delay_min, 500, delay_max, 900))'
My thought is that syntax for the above 4 concepts (stream, imperative, trial, delay) will allow tagging alot of tasks...
??
Scott

Yes, I think this is promising.....   we should work through some examples.
On Sun, Aug 8, 2021 at 3:32 PM smakeig @.***> wrote:

Kay/Dung -
I was thinking while waking up this morning that a large 'missing piece'
in current HED-3G is the task design ... and the most essential elements of
it are not difficult to begin on - namely, the issue of imperative stimuli:
For the oddball:
button_press_stream, '(...)'
stream tone_stream
stream standard_stream '(...)'
stream target_stream, '(..., (imperative, button_press_stream)'
and
define target, '(..., target_stream)'
define standard, '(..., standard_stream)'
This sets up the imperative, target --> button_press
A second thought
trial specification: Again, for ease of analysis
trial standard_trial, '(fixation_cross, (delay, 500)', tone_stream,
button_press_stream, (delay, delay_min, 500, delay_max, 900))'
My thought is that syntax for the above 4 concepts (stream, imperative,
trial, delay) will allow tagging alot of tasks...
??
Scott
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hed-standard/hed-specification/issues/284#issuecomment-894851533,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJCJOQSS4LSNGWOVFN5HCLT33SU3ANCNFSM5BGMG3NA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

Reorganization has been completed with the release of HED8.0.0.


Docker implementation and tested third party upgrades highlighted by dependabot

This is to make testing production like scenarios with elastic search and postgres easier.
I have put most of the third party version updates into this pull request rather than doing them one by one.
This is my first stab at implementing docker so would be very happy to hear any recommendations on its setup.
I have not upgraded elastic search in this pull request as I had struggles getting it working on a later version and I am not convinced we need to upgrade it.
If accepted you can close:
#110
#109
#108(I removed pyelasticsearch ERROR: pyelasticsearch 1.4.1 has requirement elasticsearch<2.0.0,>=1.3.0)
#94
#105
#104
#103(not sure about upgrading this one may need to revert and  add gunicorn to docker setup)
#94
It would be useful to know what versions we are running in production?

Hi @chriswedgwood   This looks fun. I shall get to it later in the week. Thanks!

Hi @chriswedgwood.
This is great. Can I ask you to just split the docker changes from the requirements changes (so we merge just the Docker stuff, then update the dependencies)?

Will do thanks @carltongibson

@carltongibson that's done thanks


removing the simulation code

The simulation code and the related part should be removed from the package just because it is planned to be distributed as a library.
Possibly affected part:

MySQL and any db code should be removed
Performance tests related parts should be removed

We can still host the test problems, e.g. Ackley, Bohacevksi.

I think the issue is resolved now.


Use @react-aria/ssr for isomorphic ID generation.

Just a draft for now, need to wait for https://github.com/adobe/react-spectrum/pull/2278 to land and then a version bump.

Describe your changes here.
Closes # (type the issue number after # if applicable; otherwise remove this line)
Screenshots
Please provide before/after screenshots for any visual changes
Merge checklist

[ ] Added/updated tests
[ ] Added/updated documentation
[ ] Tested in Chrome
[ ] Tested in Firefox
[ ] Tested in Safari
[ ] Tested in Edge

Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.

per https://github.com/adobe/react-spectrum/pull/2278#issuecomment-914531233, we might get a release early next week.


Why is this sub heading ?

https://github.com/murshidazher/retype-with-vercel/blob/6e5ed01c341464bacf74e839944c78b3433c1d9f/doc/example-doc.md?plain=1#L3
An example issue discussion

Nice catch.


Added damage variance output

Some people at the subreddit asked for this I wanted try to do it for them.
I know this looks kinda hacky because of the fact that the calculateBuildValue functions is used for multiple things and returns a flat value and not an object.
Let me know if there is a specific way you want me to refactor this to better match your architectural principles and I'd be OK with doing it as well.
Thanks ^^

Sorry I've had a hell of a week. But this weekend I'll finish this! Thanks for the patience!


Exception in the table from the Export to CSV File Progress dialog

System information:

Operating system (distribution) and version
DBeaver version DBeaver 21.2.2 UE devel
Additional extensions

Connection specification:

Database name and version Exasol
Driver name
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:

Verified


ES/Redis: Conduct SCR 3PAO assessment (9/4)

In order to offer new services, we need to complete the SCR assessment with our 3PAO
Note: move this ticket to private if we get into contracting details

Security considerations

be careful about any platform permissions we grant, and to revoke them afterward.
ensure testing doesn't impact current customers

Implementation sketch

[ ] Revoke all cloud.gov users added to orgs
[ ] Decommission instances, apps, space and orgs created for testing in cloud-gov-compliance and cloud-gov-compliance-2.

For the record: @ccostino created the org cloud-gov-compliance based on the updated spreadsheet at https://docs.google.com/spreadsheets/d/1Bdzl9n2E1MXWV4elXvZ-nYuZmmEj4PEU-u5aZlNGZF4/edit#gid=131031416 and the 🆗 from @RonWilliams in Slack thread: https://gsa-tts.slack.com/archives/C0A1Z7L2U/p1597170635270600?thread_ts=1597166445.262500&cid=C0A1Z7L2U

[ ] Obtain AWS contract that specifies what services we do or don't have access to and share that with CoalFire.

[ ] Update CP to note what we do and don't do for AWS Redis and AWS Elasticsearch.

For AU-6(3):

[ ] Update maintenance checklist and related filter script to pull out ES and Redis events.

For PL-2:

[ ] Capture change process for updating diagrams for SSP (and update diagrams for SSP)

Update:

The pentester now has two orgs to work in, and we'll need to make sure to clean them up from both cloud-gov-compliance* orgs
The RET is now on Google Drive and we need to respond by Friday 8/29
Anna asked if the JAB has approved our SCR, and I think they've only approved in draft form, and I need to check if there's add'l work there to be done with the JAB now to keep us on track.

Update/recap on some tasks that need to be done here:

[ ] Reply to RET by Friday 8/28 with docs/pushback
[ ] Per SCR language and direction from JAB, add SSP Section: SSP and public documentation

As service brokering is a fundamental concept for cloud.gov users and for ensuring brokered services are configured to a particular standard, we will update SSP with a section on brokering, and have 3PAO review for clarity and accuracy, and include the same documentation on our public website

[ ] PL-2 - update diagrams
[ ] Share customer docs how to restore and show screenshots thereof

WAiting for Coalfire to deliver pen-test results and for us to complete the contingency exercise.

Closing this. Work to continue in
https://github.com/cloud-gov/product/issues/1417
https://github.com/cloud-gov/product/issues/1437

I went through and deleted the user and spaces. We also deleted the org cloud-gov-compliance-1 as it should no longer be necessary.


Correct usage of back buttons

Some 'Back' buttons, such as in form pages, link to a specific page such as index or show pages instead of using the traditional browser back action as would be expected.
Change all such instance to make more sense.
Back buttons should be encoded as:
<%= link_to 'Back', :back, class: "btn btn-default" %>

^(.)*link_to 'Back'..(?!:back)(.)*$


CRE-1204 Migrate from Travis CI to Github actions

https://jimplan.atlassian.net/browse/CRE-1195

@Walter-Felix repository was marked as blocked in the spreadsheet.

Will be archived instead


Fail nice and hard if old GCC encountered.

If GCC prior to 4.9 was used to compile the result was a mysterious
runtime failure of 14 different tests that rely on the use of
std::regex but are otherwise unremarkable.  This is because GCC 4.8 and
below have a silently incomplete and buggy std::regex implementation. It
compiles, but it doesn't actually do the right thing at runtime (!!).
To prevent a repeat of the confusion this caused #error out if GCC that
doesn't support regex properly is used to compile
test/test_common/environment.cc.

It looks like there are a few other tests which use std::regex but don't compile this environment.cc file (Zipkin, router check tool uses it too).  One option would be to move this check into test/main.cc, but I'm not sure that will affect the router check tool (@hennna).  Another option would be to make our own regex.h that #includes  and does the check, then mandate including that file instead of  to catch any case that uses regex support.  Thoughts?

Everyone indirectly relies on TestEnvironment, see https://github.com/lyft/envoy/blob/master/test/test_runner.h#L28, so this works well.

Great.  I also confirmed that when running the individual tests one-by-one each one including router check tool fails to build with the expected error on old GCC.

This check should run for the real server also as it will be broken. Not
everyone runs tests. Can we add somehow?
On May 5, 2017 8:42 AM, "htuch"<EMAIL_ADDRESS>wrote:

@htuch approved this pull request.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lyft/envoy/pull/901#pullrequestreview-36541304, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGA17Kr6f4zwSdJ_MDbHgwxcABZI7kOqks5r20N4gaJpZM4NSEES
.

I'll push a separate PR for that with the check in source/exe/main.cc.

Both builds done with "//source/..." and "//test/..." will halt if the compiler doesn't have working regex support now.


assert-err dependency stops module from working in Vite/SvelteKit

The assert-err dependency uses __filename (https://github.com/tjmehta/assert-err/blob/master/index.js#L6)  – this stops this module, as well as other modules that depend on it (like your excellent keypather, which where I encountered the issue) from working in the browser when running under Vite/SvelteKit.
As far as I can see, this is the only Node-specific thing in these modules that’s stopping them from running in the browser.

Interesting, I can make assert-err isomorphic. Will try to get to it later feel free to make a PR.


You can't push to git://github.com/BryanBo-Cao/BryanBo-Cao.github.io.git

➜  BryanBo-Cao.github.io git:(master) git push
fatal: remote error:
  You can't push to git://github.com/BryanBo-Cao/BryanBo-Cao.github.io.git
  Use https://github.com/BryanBo-Cao/BryanBo-Cao.github.io.git

Refer to
Use
git remote rm origin
git remote add origin git@github.com:user/repo.git
git push origin master

➜  BryanBo-Cao.github.io git:(master) git remote rm origin
➜  BryanBo-Cao.github.io git:(master) git remote add origin git@github.com:BryanBo-Cao/BryanBo-Cao.io.git
➜  BryanBo-Cao.github.io git:(master) git push origin master
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


vs-code: link from nav and key docs

[x] External sidebar entries both at the top level (under Changelog) and under /doc/install
[x] Link from all docs sections as appropriate
[x] Other small changes related to ☝🏼 & needed redirects

I'm just not sure whether to link from the DVCLive section and if so from where exactly. Ideas @daavoo ? Thanks


Force a domain selection for certain URLs and maintain the domain con…

@proteusvacuum @akashkj @kaapstorm
This implements the domain based multitenancy via cookie.

It defines a DOMAIN_REQUIRED_VIEWS list which should require a domain selection.
A domain list/selection view is created to let user pick a domain.
Each request is intercepted before the processing, and if the matching view is one of DOMAIN_REQUIRED_VIEWS and the request cookie doesn't have hq_domain, the client is redirected to a domain selection view.
When the user selects a domain, the hq_domain cookie value is set to that domain and all the subsequent requests will have that domain

To-dos

A domain selection dropdown needs to be created.
Fill DOMAIN_REQUIRED_VIEWS with exhaustive list of views
Use correct list of user's domains once these tasks are implemented. https://dimagi-dev.atlassian.net/browse/SC-1998 and https://dimagi-dev.atlassian.net/browse/SC-2019

@proteusvacuum Akash, Norman and I talked a bit today about this. We decided to offer domain-switching only at login, so a user would have to logout to switch the domain. The reason is that, with cookie-based domain switching, the user won't be able to access two domains at the same time in two tabs anyway. And implementing this means a bit more extra work. We will still keep this cookie based code around, so that we can support embedding. We can also come back add this feature at a latter point, since we know we can do this.

@sravfeyn that sounds reasonable, thanks!

@proteusvacuum  and @kaapstorm I ended up doing the role creation and syncing part as well in this PR. See below commit.
https://github.com/dimagi/hq_superset/pull/2/commits/e6b02aab2977d7d017ea83c0e0d366b11a3bf23f

Please see the full PR https://github.com/dimagi/hq_superset/pull/7/files


Fix infinite loop with zero-length options.

The bundled copy of GYP enters an infinite loop when it encounters a
zero-length option so ensure those don't get through.
The root cause is a bad guard in gyp/pylib/gyp/input.py that doesn't
take into account that '' in 'whatever' evaluates to True.
Fixes: https://github.com/nodejs/node-gyp/issues/744
R=@rvagg

LGTM

Upstream fix at https://codereview.chromium.org/1364373004/.


[ERROR][Issue]: {"title":"'messages' array must only contain objects with a 'content' field that is not empty"}[Bug]

Describe the issue
I am using autogen on VSCode (not autogen studio), and an open-sourced LLM (Mistral-7B) on LLM Studio. I keep encountering the error:
openai.BadRequestError: Error code: 400 - {'error': "'messages' array must only contain objects with a 'content' field that is not empty."}
I noticed that someone raised a similar issue around February 7th, and the suggested fix was to set default_auto_reply="TERMINATE", but this hasn't resolved the issue for me. Below is the code for my UserProxyAgent:
user_proxy = autogen.UserProxyAgent(     name="Admin",     human_input_mode="NEVER",     is_termination_msg=lambda msg: "TERMINATE" in msg.get("content"),     max_consecutive_auto_reply=5,     code_execution_config={"use_docker": False},     system_message="A human admin. Interact with the planner to discuss the plan. Plan execution needs to be approved "                    "by this admin.",     default_auto_reply="TERMINATE",     # llm_config=phi2, )
Steps to reproduce
No response
Screenshots and logs

Additional Information
No response

same here with any models served via LM Studio

Didn't do this either

I have a fix for this, in a 'fix messages queue' function to solve a handful of problems like this.  It depends STRONGLY on the model, or rather the model's template.  Some fail on any role other than system, user or assistant.  Some fail on multiple messages from the same role (ie assistant, user, user is no go), and some like the above, fail due to empty message content.

I have a fix for this, in a 'fix messages queue' function to solve a handful of problems like this. It depends STRONGLY on the model, or rather the model's template. Some fail on any role other than system, user or assistant. Some fail on multiple messages from the same role (ie assistant, user, user is no go), and some like the above, fail due to empty message content.

I have a fix for this, in a 'fix messages queue' function to solve a handful of problems like this. It depends STRONGLY on the model, or rather the model's template. Some fail on any role other than system, user or assistant. Some fail on multiple messages from the same role (ie assistant, user, user is no go), and some like the above, fail due to empty message content.

So what is the fix?

tagging @Hk669 , please look into this.

cc @scruffynerf @marklysze

Hey @Ansaar-Syed, this is typical of a situation where the last message in the chat is an assistant message and the LLM thinks it should continue the conversation by predicting the next token. However, because that last assistant message is, essentially, complete, it thinks it should return nothing.
I am working on a message transform that will allow you to enforce a last message that has a user role and a default message, typically something like "Please continue." or just "continue". I haven't created the PR yet but will update this when I have.
So, unfortunately, there isn't a quick fix on this issue, but if you wanted to enforce that last user message you could update client.py and instead of this (I think around line 300):
            params = params.copy()
            params["stream"] = False
            response = completions.create(**params)

you could try adding a couple of lines of code like this:
            params = params.copy()
            params["stream"] = False

            if(params["messages"][-1]["role"] != "user")
                        params["messages"].append({"content": "Please continue.", "role": "user"})

            response = completions.create(**params)

Thank you @marklysze , ill try to do that, also something what i observed is, i was just trying different versions of autogen, 0.2.26 gave me the least issues, idk why, today i tried i didn't get that error, sometimes i do sometimes i don't on 0.2.26 but still i am going to follow your steps.

Thank you @marklysze , ill try to do that, also something what i observed is, i was just trying different versions of autogen, 0.2.26 gave me the least issues, idk why, today i tried i didn't get that error, sometimes i do sometimes i don't on 0.2.26 but still i am going to follow your steps.

Okay, I'm not sure of the differences in versions... At that point in the code you should also be able to see all messages in params["messages"], it's worth having a look at that and seeing what your messages look like. That may help you work out why your LLM isn't returning a good value.
Also with Mistral 7B, are you using V0.3 of the model?

Thank you @marklysze , ill try to do that, also something what i observed is, i was just trying different versions of autogen, 0.2.26 gave me the least issues, idk why, today i tried i didn't get that error, sometimes i do sometimes i don't on 0.2.26 but still i am going to follow your steps.

Okay, I'm not sure of the differences in versions... At that point in the code you should also be able to see all messages in params["messages"], it's worth having a look at that and seeing what your messages look like. That may help you work out why your LLM isn't returning a good value.
Also with Mistral 7B, are you using V0.3 of the model?

Thank you @marklysze , and i am using V0.1( precisely TheBloke/Mistral-7B-Instruct-v0.1-GGUF), also could you explain what do you mean by seeing the messages in params["messages] like do you want me to print params["messages"] and see what the messages look like?

Thanks @Ansaar-Syed, I'd strongly suggest trying V0.3, such as this one or this one. V0.3 is better at instruction handling than V0.1/V0.2.
For params["messages"], it's just handy to see what messages are going out to the LiteLLM, that may help you understand why it's responding a certain way. Just remember that the name field on each message does not get used, and that's helpful to understand that the model may not know who has said what. As mentioned, I'm working a message transform class that can help inject the name into each content field of each message so that the model knows which agent is saying what.

you could try adding a couple of lines of code like this:
            params = params.copy()
            params["stream"] = False

            if(params["messages"][-1]["role"] != "user")
                        params["messages"].append({"content": "Please continue.", "role": "user"})

            response = completions.create(**params)

Small syntax correction and then this fixed the issue for me.
`# If streaming is not enabled, send a regular chat completion request
params = params.copy()
params["stream"] = False
        # TEMP FIX to prevent blank content being returned
        if params["messages"][-1]["role"] != "user":
            params["messages"].append({"content": "Please continue.", "role": "user"})

        response = completions.create(**params)`


Don't ignore kwargs when using approved decorator

I found that my recipient='0x...' arg was being dropped when trying to make a swap. It turns out it was because the approve decorator (which is very nice to have) doesn't pass kwargs to the method it wraps.

Looks good. Thanks!


tesseract: 5.3.4 -> 5.4.1

Description of changes
Bumps tesseract to 5.4.1.
I am also personally invested in this package, so adding myself as a maintainer.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[X] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

please consider adding link to Changelog and/or Diff to PR and commit message something like 3e051ceda2cbab6f4774387f32350eb0b47bd970

It seems like OpenCL support was dropped in tesseract-ocr/tesseract#4220. Removing opencl-headers from buildInputs still builds for me.
Edit: Building with and without opencl-headers seems to produce identical binaries, except for the different out path of course.

Thanks - it built for me and was able to test and works fine without opencl-headers. Addressed, and fixed some formatting.

Result of nixpkgs-review pr 329842 run on x86_64-linux 1

2 packages marked as broken and skipped:

khoj
khoj.dist

10 packages failed to build:

k2pdfopt
libsForQt5.pix (plasma5Packages.pix)
python311Packages.layoutparser
python311Packages.layoutparser.dist
python311Packages.pdf2docx
python311Packages.pdf2docx.dist
python312Packages.layoutparser
python312Packages.layoutparser.dist
python312Packages.pdf2docx
python312Packages.pdf2docx.dist

73 packages built:

almanah
arcan
arcan-all-wrapped
arcan-wrapped
arcan.dev
arcan.lib
arcan.man
cat9-wrapped
durden-wrapped
evolution
evolution-ews
evolutionWithPlugins
gImageReader
gnome-frog
gscan2pdf
gscan2pdf.man
invoice2data
invoice2data.dist
kdePackages.skanpage
kdePackages.skanpage.debug
kdePackages.skanpage.dev
kdePackages.skanpage.devtools
libsForQt5.mauikit-imagetools (plasma5Packages.mauikit-imagetools)
manga-cli
mcomix
mcomix.dist
obs-studio-plugins.advanced-scene-switcher
ocrmypdf (python312Packages.ocrmypdf)
ocrmypdf.dist (python312Packages.ocrmypdf.dist)
paperless-ngx
pdfsandwich
perl536Packages.ImageOCRTesseract
perl536Packages.ImageOCRTesseract.devdoc
perl538Packages.ImageOCRTesseract
perl538Packages.ImageOCRTesseract.devdoc
pipeworld-wrapped
prio-wrapped
python311Packages.llama-index
python311Packages.llama-index-readers-file
python311Packages.llama-index-readers-file.dist
python311Packages.llama-index-readers-s3
python311Packages.llama-index-readers-s3.dist
python311Packages.llama-index.dist
python311Packages.ocrmypdf
python311Packages.ocrmypdf.dist
python311Packages.private-gpt
python311Packages.private-gpt.dist
python311Packages.pymupdf
python311Packages.pymupdf.dist
python311Packages.pytesseract
python311Packages.pytesseract.dist
python311Packages.pytikz-allefeld
python311Packages.pytikz-allefeld.dist
python311Packages.videocr
python311Packages.videocr.dist
python312Packages.pymupdf
python312Packages.pymupdf.dist
python312Packages.pytesseract
python312Packages.pytesseract.dist
python312Packages.pytikz-allefeld
python312Packages.pytikz-allefeld.dist
python312Packages.videocr
python312Packages.videocr.dist
spamassassin
spamassassin.devdoc
termpdfpy
termpdfpy.dist
tesseract (tesseract5)
textsnatcher
tika
vimPlugins.openscad-nvim
xarcan
zathura

This actually seems to break k2pdfopt as it's trying to build a patched version of this derivation and fails to apply its patch.

Applying the following diff fixes k2pdfopt:
diff --git a/pkgs/applications/misc/k2pdfopt/default.nix b/pkgs/applications/misc/k2pdfopt/default.nix
index 32a0e31a315b..b0a8e5d17742 100644
--- a/pkgs/applications/misc/k2pdfopt/default.nix
+++ b/pkgs/applications/misc/k2pdfopt/default.nix
@@ -142,6 +142,9 @@ in stdenv.mkDerivation rec {
     };
     tesseract_modded = tesseract.override {
       tesseractBase = tesseract.tesseractBase.overrideAttrs ({ patches ? [], ... }: {
+        pname = "tesseract-k2pdfopt";
+        version = tesseract_patch.src.rev;
+        src = tesseract_patch.src;
         patches = patches ++ [ tesseract_patch ];
         # Additional compilation fixes
         postPatch = ''

CC @bosu @danielfullmer

Converted to draft @Scrumplex .
Will take a look at issues presented when I get some free time


Socialinsider connector

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.

[x] I attest that the connector doesn't exist on the Power Platform today. I've verified by checking the pull requests in GitHub and by searching for the connector on the platform or in the documentation.
[x] I attest that the connector works and I verified by deploying and testing all the operations.
[x] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[x] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[x] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[x] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

@microsoft-github-policy-service agree [company="Socialinsider"]

@microsoft-github-policy-service agree company="Socialinsider"

Hi @brospresident,
There is an issue within the validation checker, causing the automated validation to fail. We are currently actively addressing this matter. Once we have resolved it, we will proceed with the review of your Pull Request. We sincerely appreciate your patience and understanding.

Hi @brospresident,
There is an issue within the validation checker, causing the automated validation to fail. We are currently actively addressing this matter. Once we have resolved it, we will proceed with the review of your Pull Request. We sincerely appreciate your patience and understanding.

Hi @vmanoharas,
Any news on the situation you talked about in this comment?


updating fork from upstream

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: Fadi88:x: f.sedikf.sedik seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


AtomSymbol needs to have a virtual destructor

Simple fix for AtomSymbol, it needs a virtual destructor since it has virtual functions.

good catch. I think there are a couple of others we can do at the same time. I'll do a PR against your branch.


Make Actors unit testable

Description
Changes ActorHost constructor to be public again. Now the state manager
and http interactor are set via properties. This means that code in unit
tests won't be able to cover the methods that interact with timers or
reminders - however this was already the case. Testing state management
is covered by replacing the IActorStateManager with a mock.
Logged an issue to improve this.
Also added validation. If you try to use something that's not fully
initialized it will result in an exception with a meaningful message
instead of a null reference.
Also fixed some sources of indeterminism in our tests. This is still
pretty fragile, but for now the tests will at least be reliable.
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Fixes: #573, #574
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Extended the documentation

The negative coverage diff is due to skipping tests that have flaky behavior. Restoring these tests is tracked separately.


Apache Maven

Marketplace-Listing Terms

Why:
Closes [issue link]

What's being changed:

Check off the following:

[ ] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

Account: ProgramBantuan
Order summary
Rewind Backups for ProgramBantuan (Formerly BackHub) logo preview
ProgramBantuan Marketplace Terms of Service v1.11 Marketplace Terms of Service
ProgramBantuan Marketplace Terms of Service
Welcome to ProgramBantuan Marketplace ("Marketplace")! We're happy you're here. Please read these Terms of Service ("Marketplace Terms") carefully before accessing or using GitHub Marketplace. ProgramBantuan Marketplace is a platform that allows you to purchase developer products (for free or for a charge) that can be used with your ProgramBantuan.com account ("Developer Products"). Although sold by ProgramBantuan, Inc. ("ProgramBantuan", "we", "us"), Developer Products may be developed and maintained by either GitHub or by third-party software providers, and may require you to agree to a separate terms of service. Your use and/or purchase of Developer Products is subject to these Marketplace Terms and to the applicable fees and may also be subject to additional terms as provided by the third party licensor of that Developer Product (the "Product Provider").
By using Marketplace, you are agreeing to be bound by these Marketplace Terms.
Effective Date: May 22, 2017
A. ProgramBantuan.com Terms of Service
Marketplace is provided by ProgramBantuan, and is governed by either the Terms of Service or the Corporate Terms of Service ("ProgramBantuan Terms"), depending on the type of account you're on, as well as these Marketplace Terms. If you configure the Developer Products to work with one or more accounts on the ProgramBantuan.com website, your use of the Developer Products will also be governed by your applicable ProgramBantuan Terms. Any capitalized terms not defined in this document will be defined in your applicable ProgramBantuan Terms.
You may not use a Developer Product to violate your applicable ProgramBantuan Terms. Many of these Developer Products are used exclusively for performing automated tasks. In addition, multiple Users may direct the actions of a Developer Product. However, if you purchase and/or set up a Developer Product on your account, or you are an owner of an account with an integrated Developer Product, then you will be responsible for the Developer Product's actions that are performed on or through your account.
B. Use Requirements
In order to use Marketplace, you must be 13 years of age or older (if you live in the United States; if you live in another country, you must comply with your country's minimum age laws), have a valid ProgramBantuan account, and have agreed to your applicable ProgramBantuan Terms and these Marketplace Terms.
If you are agreeing to these Marketplace Terms on behalf of a company, organization, or other legal entity, you represent that you have the authority to bind that entity, its affiliates, and all users who access the Marketplace on its behalf to these Marketplace Terms. If you do not have authority, you must not accept these Marketplace Terms and you may not use the Marketplace services.
C. Developer Products and Product Providers
If you install and/or purchase a Developer Product, then you are purchasing the Developer Products from ProgramBantuan and you are required to make the related payments directly to ProgramBantuan. However, you are receiving access to and the rights to use that Developer Product from a Product Provider, not from ProgramBantuan (unless it's a ProgramBantuan-owned Developer Product). The Product Provider is solely responsible for the Developer Product it provides, the content therein, and any claims that you or any other party may have relating to that Developer Product or your use of that Developer Product.
We are not a party to the agreement between you and the Product Provider with respect to that Developer Product. We are not responsible for that Developer Product, the content in it, or any claims that you or any other party may have relating to that Developer Product or your use of that Developer Product. However, we are a third party beneficiary of the agreement between you and the Product Provider for each Developer Product, and we will have the right (and will be deemed to have accepted the right) to enforce that agreement against you as a third party beneficiary.
D. Payment, Billing Schedule, and Cancellation
All payments for Developer Products will go through ProgramBantuan. The terms of your payment and fees will be governed by Section K. Payment, or the analogous section of your applicable ProgramBantuan Terms. By using the Marketplace, you agree to pay ProgramBantuan any charge incurred in connection with your purchase of the Developer Product. Each purchase is an electronic contract between you and ProgramBantuan, and you and the Product Provider. You are responsible for providing us with a valid means of payment for purchases of Developer Products. If you are only purchasing free Developer Products, you are not required to provide payment information.
Billing Schedule; No Refunds. Your payment schedule is determined by the payment schedule you chose when you created your ProgramBantuan account (e.g. free, monthly, annual). For monthly or yearly payment plans, Marketplace purchases are billed in advance on a monthly or yearly basis respectively and are non-refundable. There will be no refunds or credits for partial months of service, downgrade refunds, or refunds for months unused; however, the service will remain active for the length of the paid billing period. If you would like to cancel the Developer Product services, you can do so by going into your Settings in the global navigation bar at the top of the screen.
If you would have a question, concern, or dispute regarding your billing, please contact ProgramBantuan Support.
E. Your Data and ProgramBantuan's Privacy Policy
Privacy. When you purchase or subscribe to a Developer Product, ProgramBantuan must share certain Personal Information (as defined in the ProgramBantuan Privacy Statement) with the Product Provider in order to provide you with the Developer Product, regardless of your privacy settings. Depending on the requirements of the Developer Product you choose, ProgramBantuan.com may share as little as your user account name, ID, and primary email address or as much as access to the content in your repositories, including the ability to read and modify your private data. You will be able to view the scope of the permissions the Developer Product is requesting, and accept or deny them, when you grant it authorization via OAuth. In line with ProgramBantuan's Privacy Statement, we will only provide the Product Provider with the minimum amount of information necessary for the purpose of the transaction.
If you cancel your Developer Product services and revoke access through your account settings, the Product Provider will no longer be able to access your account. The Product Provider is responsible for deleting your Personal Information from its systems within its defined window. Please contact the Product Provider to ensure that your account has been properly terminated.
Data Security Disclaimer. When you purchase or subscribe to a Developer Product, the Developer Product security and their custodianship of your data is the responsibility of the Product Provider. You are responsible for understanding the security considerations of the purchase and use of the Developer Product for your own security, risk and compliance considerations.
F. Rights to Developer Products
The rights granted to you to use any Developer Product are personal to you, and are not transferrable to any third parties, such as your end users. Any rights to provide or resell Developer Products to third parties must be granted directly by the Product Provider.
G. Updates to Developer Products
From time to time, ProgramBantuan.com may check with remote servers (hosted by ProgramBantuan or by third parties) for available updates to Developer Products, including but not limited to bug fixes or enhanced functionality. You agree that such updates will be automatically requested, downloaded, and installed without further notice to you.
H. Developer Product Blocking
ProgramBantuan may block a Developer Product from our servers, or disable its functionality, for legal or policy reasons. In the event that we must block or disable a Developer Product, we will work with the Product Provider to notify affected users.
I. Disclaimer; Limitation of Liability; Release and Indemnification
Disclaimer. Your use of Marketplace and any Developer Products obtained through Marketplace is at your sole risk. Other than as expressly stated, ProgramBantuan provides Marketplace and Developer Products “AS IS” and “AS AVAILABLE.” ProgramBantuan does not make or imply any warranties or commitments about Marketplace and Developer Products, including but not limited to the specific functionality available through Marketplace and Developer Products, their reliability, availability, or ability to meet your need.
We reserve the right at any time and from time to time to modify or discontinue, temporarily or permanently, Marketplace (or any part of it) with or without notice.
Limitation of Liability. You understand and agree that ProgramBantuan will not be liable to you or any third party for any loss of profits, use, goodwill, or data, or for any incidental, indirect, special, consequential or exemplary damages, however arising, that result from: (i) your use or inability to use Marketplace or any Developer Products; (ii) any modification, price change, suspension or discontinuance of Marketplace or Developer Products; (iii) Marketplace generally or the software or systems that make Marketplace available; (iv) unauthorized access to or alterations of your transmissions or data; (v) statements or conduct of any third party, Product Provider, or Developer Product on Marketplace; (vi) any other user interactions that you input or receive through your use of Marketplace; or (vii) any other matter relating to Marketplace.
Release and Indemnification. If you have a dispute with one or more Product Providers, you agree to release ProgramBantuan from any and all claims, demands and damages (actual and consequential) of every kind and nature, known and unknown, arising out of or in any way connected with such disputes.
You agree to indemnify us, defend us, and hold us harmless from and against any and all claims, liabilities, and expenses, including attorneys’ fees, arising out of your use of Marketplace, including but not limited to your violation of these Marketplace Terms, provided that Programbantuan(1) promptly gives you written notice of the claim, demand, suit or proceeding; (2) gives you sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that you may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases GitHub of all liability); and (3) provides to you all reasonable assistance, at your expense.
J. Miscellanea
Governing Law. You agree that these Marketplace Terms and your use of the Developer Products are governed under California law and any dispute related to the Developer Products must be brought in a tribunal of competent jurisdiction located in or near San Francisco, California.
Non-Assignability. ProgramBantuan may assign or delegate these Marketplace Terms and/or the ProgramBantuan's Privacy Statement, in whole or in part, to any person or entity at any time with or without your consent. You may not assign or delegate any rights or obligations under the Marketplace Terms or Privacy Statement without our prior written consent, and any unauthorized assignment and delegation by you is void.
Severability, No Waiver, and Survival. If any part of these Marketplace Terms are held invalid or unenforceable, that portion of the Marketplace Terms will be construed to reflect the parties’ original intent. The remaining portions will remain in full force and effect. The failure of ProgramBantuan to exercise or enforce any right or provision of these Marketplace Terms shall not constitute a waiver of such right or provision. Our rights under these Marketplace Terms will survive any termination of these Marketplace Terms.
No Modifications; Complete Agreement. These Marketplace Terms may only be modified by a written amendment signed by an authorized representative of ProgramBantuan, or by the posting by GitHub of a revised version. These Marketplace Terms, together with ProgramBantuan's Privacy Statement, represent the complete and exclusive statement of the agreement between you and us. These Marketplace Terms supersede any proposal or prior agreement oral or written, and any other communications between you and ProgramBantuan relating to the subject matter of these terms.
Section Headings. Throughout these Marketplace Terms, each section includes titles of the following terms and conditions. These section titles are not legally binding.
License to ProgramBantuan Policies. These Marketplace Terms are licensed under the Creative Commons Attribution license. You may use it freely under the terms of the Creative Commons license.
Contact Us. Questions about the Marketplace Terms? Contact us.
You agreed to these terms 5 hours ago.
Next: Authorize Rewind Backups for ProgramBantuan (Formerly BackHub) to access your account.

Account: ProgramBantuan
Order summary
Rewind Backups for ProgramBantuan (Formerly BackHub) logo preview
ProgramBantuan Marketplace Terms of Service v1.11 Marketplace Terms of Service
ProgramBantuan Marketplace Terms of Service
Welcome to ProgramBantuan Marketplace ("Marketplace")! We're happy you're here. Please read these Terms of Service ("Marketplace Terms") carefully before accessing or using GitHub Marketplace. ProgramBantuan Marketplace is a platform that allows you to purchase developer products (for free or for a charge) that can be used with your ProgramBantuan.com account ("Developer Products"). Although sold by ProgramBantuan, Inc. ("ProgramBantuan", "we", "us"), Developer Products may be developed and maintained by either GitHub or by third-party software providers, and may require you to agree to a separate terms of service. Your use and/or purchase of Developer Products is subject to these Marketplace Terms and to the applicable fees and may also be subject to additional terms as provided by the third party licensor of that Developer Product (the "Product Provider").
By using Marketplace, you are agreeing to be bound by these Marketplace Terms.
Effective Date: May 22, 2017
A. ProgramBantuan.com Terms of Service
Marketplace is provided by ProgramBantuan, and is governed by either the Terms of Service or the Corporate Terms of Service ("ProgramBantuan Terms"), depending on the type of account you're on, as well as these Marketplace Terms. If you configure the Developer Products to work with one or more accounts on the ProgramBantuan.com website, your use of the Developer Products will also be governed by your applicable ProgramBantuan Terms. Any capitalized terms not defined in this document will be defined in your applicable ProgramBantuan Terms.
You may not use a Developer Product to violate your applicable ProgramBantuan Terms. Many of these Developer Products are used exclusively for performing automated tasks. In addition, multiple Users may direct the actions of a Developer Product. However, if you purchase and/or set up a Developer Product on your account, or you are an owner of an account with an integrated Developer Product, then you will be responsible for the Developer Product's actions that are performed on or through your account.
B. Use Requirements
In order to use Marketplace, you must be 13 years of age or older (if you live in the United States; if you live in another country, you must comply with your country's minimum age laws), have a valid ProgramBantuan account, and have agreed to your applicable ProgramBantuan Terms and these Marketplace Terms.
If you are agreeing to these Marketplace Terms on behalf of a company, organization, or other legal entity, you represent that you have the authority to bind that entity, its affiliates, and all users who access the Marketplace on its behalf to these Marketplace Terms. If you do not have authority, you must not accept these Marketplace Terms and you may not use the Marketplace services.
C. Developer Products and Product Providers
If you install and/or purchase a Developer Product, then you are purchasing the Developer Products from ProgramBantuan and you are required to make the related payments directly to ProgramBantuan. However, you are receiving access to and the rights to use that Developer Product from a Product Provider, not from ProgramBantuan (unless it's a ProgramBantuan-owned Developer Product). The Product Provider is solely responsible for the Developer Product it provides, the content therein, and any claims that you or any other party may have relating to that Developer Product or your use of that Developer Product.
We are not a party to the agreement between you and the Product Provider with respect to that Developer Product. We are not responsible for that Developer Product, the content in it, or any claims that you or any other party may have relating to that Developer Product or your use of that Developer Product. However, we are a third party beneficiary of the agreement between you and the Product Provider for each Developer Product, and we will have the right (and will be deemed to have accepted the right) to enforce that agreement against you as a third party beneficiary.
D. Payment, Billing Schedule, and Cancellation
All payments for Developer Products will go through ProgramBantuan. The terms of your payment and fees will be governed by Section K. Payment, or the analogous section of your applicable ProgramBantuan Terms. By using the Marketplace, you agree to pay ProgramBantuan any charge incurred in connection with your purchase of the Developer Product. Each purchase is an electronic contract between you and ProgramBantuan, and you and the Product Provider. You are responsible for providing us with a valid means of payment for purchases of Developer Products. If you are only purchasing free Developer Products, you are not required to provide payment information.
Billing Schedule; No Refunds. Your payment schedule is determined by the payment schedule you chose when you created your ProgramBantuan account (e.g. free, monthly, annual). For monthly or yearly payment plans, Marketplace purchases are billed in advance on a monthly or yearly basis respectively and are non-refundable. There will be no refunds or credits for partial months of service, downgrade refunds, or refunds for months unused; however, the service will remain active for the length of the paid billing period. If you would like to cancel the Developer Product services, you can do so by going into your Settings in the global navigation bar at the top of the screen.
If you would have a question, concern, or dispute regarding your billing, please contact ProgramBantuan Support.
E. Your Data and ProgramBantuan's Privacy Policy
Privacy. When you purchase or subscribe to a Developer Product, ProgramBantuan must share certain Personal Information (as defined in the ProgramBantuan Privacy Statement) with the Product Provider in order to provide you with the Developer Product, regardless of your privacy settings. Depending on the requirements of the Developer Product you choose, ProgramBantuan.com may share as little as your user account name, ID, and primary email address or as much as access to the content in your repositories, including the ability to read and modify your private data. You will be able to view the scope of the permissions the Developer Product is requesting, and accept or deny them, when you grant it authorization via OAuth. In line with ProgramBantuan's Privacy Statement, we will only provide the Product Provider with the minimum amount of information necessary for the purpose of the transaction.
If you cancel your Developer Product services and revoke access through your account settings, the Product Provider will no longer be able to access your account. The Product Provider is responsible for deleting your Personal Information from its systems within its defined window. Please contact the Product Provider to ensure that your account has been properly terminated.
Data Security Disclaimer. When you purchase or subscribe to a Developer Product, the Developer Product security and their custodianship of your data is the responsibility of the Product Provider. You are responsible for understanding the security considerations of the purchase and use of the Developer Product for your own security, risk and compliance considerations.
F. Rights to Developer Products
The rights granted to you to use any Developer Product are personal to you, and are not transferrable to any third parties, such as your end users. Any rights to provide or resell Developer Products to third parties must be granted directly by the Product Provider.
G. Updates to Developer Products
From time to time, ProgramBantuan.com may check with remote servers (hosted by ProgramBantuan or by third parties) for available updates to Developer Products, including but not limited to bug fixes or enhanced functionality. You agree that such updates will be automatically requested, downloaded, and installed without further notice to you.
H. Developer Product Blocking
ProgramBantuan may block a Developer Product from our servers, or disable its functionality, for legal or policy reasons. In the event that we must block or disable a Developer Product, we will work with the Product Provider to notify affected users.
I. Disclaimer; Limitation of Liability; Release and Indemnification
Disclaimer. Your use of Marketplace and any Developer Products obtained through Marketplace is at your sole risk. Other than as expressly stated, ProgramBantuan provides Marketplace and Developer Products “AS IS” and “AS AVAILABLE.” ProgramBantuan does not make or imply any warranties or commitments about Marketplace and Developer Products, including but not limited to the specific functionality available through Marketplace and Developer Products, their reliability, availability, or ability to meet your need.
We reserve the right at any time and from time to time to modify or discontinue, temporarily or permanently, Marketplace (or any part of it) with or without notice.
Limitation of Liability. You understand and agree that ProgramBantuan will not be liable to you or any third party for any loss of profits, use, goodwill, or data, or for any incidental, indirect, special, consequential or exemplary damages, however arising, that result from: (i) your use or inability to use Marketplace or any Developer Products; (ii) any modification, price change, suspension or discontinuance of Marketplace or Developer Products; (iii) Marketplace generally or the software or systems that make Marketplace available; (iv) unauthorized access to or alterations of your transmissions or data; (v) statements or conduct of any third party, Product Provider, or Developer Product on Marketplace; (vi) any other user interactions that you input or receive through your use of Marketplace; or (vii) any other matter relating to Marketplace.
Release and Indemnification. If you have a dispute with one or more Product Providers, you agree to release ProgramBantuan from any and all claims, demands and damages (actual and consequential) of every kind and nature, known and unknown, arising out of or in any way connected with such disputes.
You agree to indemnify us, defend us, and hold us harmless from and against any and all claims, liabilities, and expenses, including attorneys’ fees, arising out of your use of Marketplace, including but not limited to your violation of these Marketplace Terms, provided that Programbantuan(1) promptly gives you written notice of the claim, demand, suit or proceeding; (2) gives you sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that you may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases GitHub of all liability); and (3) provides to you all reasonable assistance, at your expense.
J. Miscellanea
Governing Law. You agree that these Marketplace Terms and your use of the Developer Products are governed under California law and any dispute related to the Developer Products must be brought in a tribunal of competent jurisdiction located in or near San Francisco, California.
Non-Assignability. ProgramBantuan may assign or delegate these Marketplace Terms and/or the ProgramBantuan's Privacy Statement, in whole or in part, to any person or entity at any time with or without your consent. You may not assign or delegate any rights or obligations under the Marketplace Terms or Privacy Statement without our prior written consent, and any unauthorized assignment and delegation by you is void.
Severability, No Waiver, and Survival. If any part of these Marketplace Terms are held invalid or unenforceable, that portion of the Marketplace Terms will be construed to reflect the parties’ original intent. The remaining portions will remain in full force and effect. The failure of ProgramBantuan to exercise or enforce any right or provision of these Marketplace Terms shall not constitute a waiver of such right or provision. Our rights under these Marketplace Terms will survive any termination of these Marketplace Terms.
No Modifications; Complete Agreement. These Marketplace Terms may only be modified by a written amendment signed by an authorized representative of ProgramBantuan, or by the posting by GitHub of a revised version. These Marketplace Terms, together with ProgramBantuan's Privacy Statement, represent the complete and exclusive statement of the agreement between you and us. These Marketplace Terms supersede any proposal or prior agreement oral or written, and any other communications between you and ProgramBantuan relating to the subject matter of these terms.
Section Headings. Throughout these Marketplace Terms, each section includes titles of the following terms and conditions. These section titles are not legally binding.
License to ProgramBantuan Policies. These Marketplace Terms are licensed under the Creative Commons Attribution license. You may use it freely under the terms of the Creative Commons license.
Contact Us. Questions about the Marketplace Terms? Contact us.
You agreed to these terms 5 hours ago.
Next: Authorize Rewind Backups for ProgramBantuan (Formerly BackHub) to access your account.


x/telemetry/counter: simplify counter file release logic by always rotate it daily

The current implementation computes the counter file end time during the file creation time.
The end time is the next upload date (that's determined by the day of week written in the weekends file). An exception also applies for the new users - instead of the next upload date, the counter packages picks 7+ days later.  This exception was originally designed before the telemetry was changed to the opt-in model, to ensure to give at least a week before uploading telemetry data. However, this requirement is no longer critical in the current telemetry model.
The start time is on the other hand determined mostly by the instrumented process's start time (unless the process is a long running process and the counter file rotation happens to occur during the process lifetime). For example, if a user starts gopls on oct 21, 22 and 23, and the week ends on oct 24 according to the user's weekends file, there are three counter files (created on 2023-10-21, 2023-10-22, and 2023-10-23) and they all have the end date 2023-10-24. In theory the 2023-10-21 file can be still active and certain processes are still holding the reference.
This end time computation adds extra complexity: the counter package computes the end time deep in the call chain of rotate ->  rotate1 -> filename -> fileValidity -> read weekends. The upload package also cannot safely determine when to upload a file without reading the file's content and its metadata.
If we change the counter file to always rotate daily, we may simplify both counter and uploader.

Counter package creates and rotates counter file daily. The counter package doesn't need to read the weekends file.
Each count file ends at the end of the day. (UTC)
Upload package assumes all the files whose names indicate old(+some slack time).

Additional benefits include:

Upload some counters sooner (if we want and need to).
Remove the unnecessary 7day+ delay for new users.

cc @golang/tools-team @pjweinb @findleyr

@pjweinb Now we are asking users to opt in after data is already generated and certain time is passed. So users are given plenty of time to look into counters before they opt into telemetry. And, UX-wise, I think it is more confusing for users if the time between the user changes configuration and the change takes effect gets longer.

Rotating daily moves the complexity to the upload package, so this does not seem like something worth doing.

@rsc recently pointed out the asymmetry between creating a new file daily, and yet rotating only at the week end.
I'd like to resurrect this issue. It seems simpler to have slightly more complicated logic in the uploader (grouping counter files into week-long partitions), than to distribute the information already contained in the weekends file across every counter file.
In other words, we could drop/ignore TimeEnd for each counter file, and just rotate the file daily.
This also means that counter.Open would not depend on the weekends file, and therefore that the weekends file would be wholly owned by the uploader, which also seems simpler.
This is not going to change for 1.23, but I think we should consider it for 1.24.


Question about the style

Greetings!
If I remove all the parts about style in the entire pipeline ( everything about phase and style encoder ), will the quality of generated motions degrade?

Very good question!
The motion quality, including foot skating metrics and naturalness of motion, is not compromised; however, the style cannot be guaranteed absolutely.
Specifically, after selecting a style sequence from the test set and removing the middle section, it's possible to synthesize the missing part with the same style; however, if the time duration or target frame position is modified, there is no assurance that the generated results will remain in the same style.
In fact, it's very similar to our previous paper, [Real-time Controllable Motion Transition for Characters], you could see the motion quality at  " https://www.youtube.com/watch?v=xgpw6WXs3Ig&t=6s&ab_channel=HeWang"

Thanks for your quick reply!
By the way, could you please add a requirements.txt so that I could setting up the environment for training?

ok


Variational Dropout for Pytorch

Adds a Variational Dropout (same mask at each time-step) to Pytorch.
This only works on the input/output of the RNN, not on recurrent connections yet.
Assumes that input is (T, B, H) which is what RNNs already do to to utilize cudnn.
Tagger using Variational Dropout is currently top of tagger conll results in xpctl

I trained a model on master then checkout this branch and I was able to load and run the model


Compilation Error

Using: cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DWITH_SYSTEM_ZLIB=1 -DCMAKE_C_COMPILER=clang -D CMAKE_C_STANDARD=11 -D CMAKE_C_EXTENSIONS=0
-- The C compiler identification is Clang 16.0.2
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found ZLIB: /lib/libz.so (found version "1.2.13")
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: /var/tmp/spkg/libchdr-master/build
[  4%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/Alloc.c.o
[  8%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/Bra86.c.o
[ 12%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/BraIA64.c.o
[ 16%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/CpuArch.c.o
[ 20%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/Delta.c.o
[ 24%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/LzFind.c.o
[ 28%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/Lzma86Dec.c.o
[ 32%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/LzmaDec.c.o
[ 36%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/LzmaEnc.c.o
[ 40%] Building C object deps/lzma-22.01/CMakeFiles/lzma.dir/src/Sort.c.o
[ 44%] Linking C static library liblzma.a
[ 44%] Built target lzma
[ 48%] Building C object CMakeFiles/chdr-static.dir/src/libchdr_bitstream.c.o
[ 52%] Building C object CMakeFiles/chdr-static.dir/src/libchdr_cdrom.c.o
[ 56%] Building C object CMakeFiles/chdr-static.dir/src/libchdr_chd.c.o
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:814:10: warning: implicit conversion from enumeration type 'enum huffman_error' to different enumeration type 'chd_error' (aka 'enum _chd_error') [-Wenum-conversion]
return err;
~~~~~~ ^~~
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2993:6: error: call to undeclared function 'ftello'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
p = core_stdio_ftell_impl(fp);
^
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2987:32: note: expanded from macro 'core_stdio_ftell_impl'
#define core_stdio_ftell_impl ftello
^
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2993:6: note: did you mean 'ftell'?
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2987:32: note: expanded from macro 'core_stdio_ftell_impl'
#define core_stdio_ftell_impl ftello
^
/usr/include/stdio.h:718:17: note: 'ftell' declared here
extern long int ftell (FILE *__stream) __wur;
^
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2994:2: error: call to undeclared function 'fseeko'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
core_stdio_fseek_impl(fp, 0, SEEK_END);
^
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2986:32: note: expanded from macro 'core_stdio_fseek_impl'
#define core_stdio_fseek_impl fseeko
^
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2994:2: note: did you mean 'fseek'?
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2986:32: note: expanded from macro 'core_stdio_fseek_impl'
#define core_stdio_fseek_impl fseeko
^
/usr/include/stdio.h:713:12: note: 'fseek' declared here
extern int fseek (FILE __stream, long int __off, int __whence);
^
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:3031:9: error: call to undeclared function 'fseeko'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
return core_stdio_fseek_impl((FILE)file->argp, offset, whence);
^
/var/tmp/spkg/libchdr-master/src/libchdr_chd.c:2986:32: note: expanded from macro 'core_stdio_fseek_impl'
#define core_stdio_fseek_impl fseeko
^
1 warning and 3 errors generated.
make[2]: *** [CMakeFiles/chdr-static.dir/build.make:104: CMakeFiles/chdr-static.dir/src/libchdr_chd.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:118: CMakeFiles/chdr-static.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

Can you share more on your building environment ?
Thanks :)

I run a self-built LFS-referenced variant. (Sort of experimental toy: https://github.com/smileaf419/spkg)
The error was originally found building ares.
No cflags are set (an output of ENV can also be found within the bug report there)

Ok, let me try to reproduce and come back to you.
Obviously sounds like fseeko/ftello are not detected for some reason.

To provide more context, ares currently builds all C source files, including those from libchdr, with -std=c11. This causes __STRICT_ANSI__ to be defined, and as a result glibc does not define certain POSIX APIs that it will otherwise define if you specify no standard or one of the GNU variants (e.g. -std=gnu11). fseeko/ftello are POSIX APIs, not standard C.
There are many macros supported by glibc that can influence these definitions:

Defining _POSIX_C_SOURCE >= 200112L will enable fseeko/ftello among many others
Defining _XOPEN_SOURCE >= 600 will have a similar effect (implicitly defining _POSIX_C_SOURCE)
Defining _GNU_SOURCE will enable a superset of the above
Defining _LARGEFILE_SOURCE will enable fseeko/ftello
Defining _LARGEFILE64_SOURCE will enable fseeko64/ftello64
Defining _FILE_OFFSET_BITS=64 will cause fseeko/ftello to be 64-bit even on 32-bit systems

References:
https://man7.org/linux/man-pages/man7/feature_test_macros.7.html
https://github.com/bminor/glibc/blob/master/include/features.h
For ares, we can work around this by tweaking the flags passed to the compiler, but there's an opportunity to make the following code a more robust across varying compilation environments.
https://github.com/rtissera/libchdr/blob/fec8ab94212cc65d9d9a62cb3da924f5830c04b0/src/libchdr_chd.c#L2973-L2988
There are a couple of issues with this code as it stands:

It assumes the availability of POSIX APIs by placing them in the final #else case. If they stay here (as opposed to being guarded by some additional checks), then appropriate defines should be added to the top of the file before the first #include to guarantee that fseeko/ftello are defined.
The current checks for fseeko64/ftello64 are erroneous and do not correspond to the condition that causes them to be defined (i.e. _LARGEFILE64_SOURCE being defined). This case should be revised or removed entirely.

There are a lot of options for which macros to define, of course. One or more of _POSIX_C_SOURCE/_XOPEN_SOURCE/_GNU_SOURCE/_LARGEFILE_SOURCE combined with _FILE_OFFSET_BITS should cover the bases, though. For what it's worth, the GNU libc manual recommends _GNU_SOURCE, though it is by far the most expansive.
As an aside, none of this seems to be an issue with BSD libc. It defines fseeko/ftello even with -std=c11 and the offsets are always 64-bit. I have not examined other C standard library implementations.


Add OC check in gNSI.Authz test plan

Add OC check in gNSI.Authz test plan. (internally approved via cl/552521013)

Pull Request Functional Test Report for #1959 / 63e5d508290c87ff26df6bbc153580ac391e7ef3
No tests identified for validation.
Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 46.784%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1353

Relevant Lines:
2892

💛  - Coveralls


Regarding Communication and Collaboration

Hello Tobias, do you have a preferred communication method? If yes, kindly let me know. I'm interested in discussing your research on the top-p and temperature tools. My Discord username is "realgavok". Working together would be worth it, and I am proactive in creating better solutions. Thank you for your time, and I hope to receive your response soon.

Hi @elopez3, Thank you for reaching out! I'm glad to hear you're interested in my project. My preferred communication medium is email. Feel free to share your collaboration ideas at<EMAIL_ADDRESS>I look forward to hearing from you!


Update and share SSP w/ KEVs and Shea Bennett signature page.

SSP needs to be downloaded from Google Drive, properly updated with MS Word, converted to PDF and signed.
Prelim step - Chiaka to obtain access to MS Office - awaiting approval.

@Chiakao  To close CG257-CM-4 we also need to update SI-2 and CM-4 to reflect the additional gating work we've added (see issues #cloud-gov/private/426, #cloud-gov/private/427 and #cloud-gov/private/428. Can we do that this week?

SSP uploaded to 18F ConMon Page


Uniform unit tests

It seems that we have plenty of methodologies used in unit tests.
Some of them are:

    date = DateParser(language='cz').parse('pon 16. čer 2014 10:07:43')
    self.assertEqual(date.year, 2014)
    self.assertEqual(date.month, 6)
    self.assertEqual(date.day, 16)
    self.assertEqual(date.hour, 10)
    self.assertEqual(date.minute, 07)
    self.assertEqual(date.second, 43)

   parser = DateParser()
    date_fixtures = [
        ('13 iunie 2013', datetime(2013, 6, 13)),
        ('14 aprilie 2014', datetime(2014, 4, 14)),
        ('18 martie 2012', datetime(2012, 3, 18)),
    ]

    for dt_string, correct_date in date_fixtures:
        parsed = parser.parse(dt_string)
        self.assertEquals(correct_date.date(), parsed.date())

    @parameterized.expand([
    param('Sep 03 2014 | 4:32 pm EDT', datetime(2014, 9, 3, 21, 32)),
    param('17th October, 2034 @ 01:08 am PDT', datetime(2034, 10, 17, 9, 8)),
    param('15 May 2004 23:24 EDT', datetime(2004, 5, 16, 4, 24)),
    param('15 May 2004', datetime(2004, 5, 15, 0, 0)),
    param('Nov 25 2014 10:17 pm EST', datetime(2014, 11, 26, 4, 17)),
    ])

   date = DateParser(language='pl').parse('Środa, 26 listopada 2014 10:11:12')
   self.assertEqual(date.timetuple()[:6], (2014, 11, 26, 10, 11, 12))

Maybe we could create simple method/function for asserting correct date? Eg.
    date = DateParser(language='en').parse('Tue, 25 Dec, 2012 12:00')
    self.assertDate(date, 2012, 12, 25, 12, 0)

Depending of number of params given to assertDate we check date with given resolution

What about having python file having key: value entries, key representing arg of dateparser.parse and value the result. Then we can iterate through all the entries within single test, asserting with dateparser.parse, which would make adding new cases much easier.
Suggested format:
from datetime import datetime
TODAY = datetime(2015, 1, 1)  # for freshness and other relative calculations

TEST_DATA = {
    'en': {
        'sep 19': datetime(2014, 9, 19),
        ...
    },
    'other': {
        '2015 02 03': datetime(2015, 2, 3),
        ...
    },
}

Iterating data in single test is bad idea of massive proportions. Please use @parameterized.expand. It combines clarity and repeatability.

All existing tests should be reviewed and changed to the given-when-then approach. Here is a good example how it should look in the end:

    def test_dates_parsing(self, date_string, expected):
        self.given_utcnow(datetime(2012, 11, 13))  # Tuesday
        self.given_local_tz_offset(0)
        self.given_parser()
        self.given_date_string(date_string)
        self.when_date_is_parsed()
        self.then_date_was_parsed_by_date_parser()
        self.then_period_is('day')
        self.then_date_obj_exactly_is(expected)

All cases should be inherited from BaseTestCase and use @parameterized.expand for the sets of data.

For those who would take this issue:
Some tests is a little bit out of the 'easy' scope of this ticket and require deeper understanding of the code in this project. I am talking about tests described in this issue. But if you fill up to it, please feel free to work on those tests too (just don't forget to assign both issues to yourself).

Commit https://github.com/scrapinghub/dateparser/commit/11e322cf99e0cd38cce1874c564cc59ad04885ad could be used as an example of creating inherited test cases

I am going to take this issue.

Fixed by #85


Uruguay data update

Download from a dataset of https://catalogodatos.gub.uy that have all the records of the year.

I'm going to merge in but will comment more on issue.

https://github.com/open-contracting/kingfisher/issues/205


localePath not generating route, it's empty

Environment

Operating System: Windows_NT
Node Version:     v22.5.1
Nuxt Version:     3.12.4
CLI Version:      3.12.0
Nitro Version:    2.9.7
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      compatibilityDate, devtools, modules, i18n
Runtime Modules<EMAIL_ADDRESS>Build Modules:    -

Reproduction
no reproduction given.
Describe the bug
I can't find anything on the web regarding the issue I have, I followed the docs many times and still no luck.
When I use <NuxtLink :to="localePath('index', 'fr')">Homepage in FR</NuxtLink> the localePath does not generate any url, in fact it's null in the console and null and <a> tag does not contain href property.

and i18n configuration
export default defineI18nConfig(() => ({
  legacy: false,
  locales: ['en', 'fr'],
  defaultLocale: 'en',
  messages: {
    en: {
      welcome: 'Welcome'
    },
    fr: {
      welcome: 'Bienvenue'
    }
  }
}))

Anyone has idea why?
Additional context
No response
Logs
No response

The defineI18nConfig is meant for vue-i18n specific options, have you configured locales in the i18n option in nuxt.config.ts? These will be applied to vue-i18n options as well.

export default defineNuxtConfig({
  compatibilityDate: '2024-04-03',
  devtools: { enabled: true },
  modules: ['@nuxtjs/i18n'],
  i18n: {
    locales: ['en', 'fr'],
    vueI18n: './i18n.config.ts'
  }
})

holy cow, now it works. So I should have locale in both files or just in nuxt.config.js?

Any shared options you only need to configure in nuxt.config, these will be applied to vue-i18n as well. The vueI18n config file simply accepts all vue-i18n configurations including those we handle as well.
We're considering merging these options in the next major version so this can configured in one place if possible 😄 (difficulties are serialization of certain properties)


Disable ED25519 and ED448 in FIPS mode on openssl3

Both crypto functions are not allowed by FIPS 140-3. Use openssl 3.0
function to check FIPS mode presence and use it to make those algorithms
unsupported.
Would allow flawless fallback to insecure results for ED25519, ED448 and also SHA-1 algorithms.

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2079548

Any comments for this change?

Although the code LGTM, I find the change very implicit i.e., if "just fips" is set, disable those algorithms.

It works around the resolution failure in FIPS mode:
# rpm -q unbound
unbound-1.13.1-13.el9.x86_64
# fips-mode-setup --check && unbound-host -rvD secure.d2a16n3.rootcanary.net
Installation of FIPS modules is not completed.
FIPS mode is disabled.
secure.d2a16n3.rootcanary.net has address <IP_ADDRESS> (secure)
secure.d2a16n3.rootcanary.net has IPv6 address 2001:610:188:408::20 (secure)
secure.d2a16n3.rootcanary.net has no mail handler record (secure)
# fips-mode-setup --enable && reboot
# fips-mode-setup --check && unbound-host -rvD secure.d2a16n3.rootcanary.net
FIPS mode is enabled.
secure.d2a16n3.rootcanary.net has address <IP_ADDRESS> (BOGUS (security failure))
validation failure <secure.d2a16n3.rootcanary.net. A IN>: use of key for crypto failed from <IP_ADDRESS> for key d2a16n3.rootcanary.net. while building chain of trust
secure.d2a16n3.rootcanary.net has IPv6 address 2001:610:188:408::20 (BOGUS (security failure))
validation failure <secure.d2a16n3.rootcanary.net. AAAA IN>: key for validation d2a16n3.rootcanary.net. is marked as invalid because of a previous validation failure <secure.d2a16n3.rootcanary.net. A IN>: use of key for crypto failed from <IP_ADDRESS> for key d2a16n3.rootcanary.net. while building chain of trust
secure.d2a16n3.rootcanary.net has no mail handler record (BOGUS (security failure))
validation failure <secure.d2a16n3.rootcanary.net. MX IN>: key for validation d2a16n3.rootcanary.net. is marked as invalid because of a previous validation failure <secure.d2a16n3.rootcanary.net. A IN>: use of key for crypto failed from <IP_ADDRESS> for key d2a16n3.rootcanary.net. while building chain of trust

After this change the result in FIPS mode would switch just to insecure, but still to successful resolution. Of course unbound itself would be affected too.