Claim name returned is strange

Via Lex:
working on unit tests for the claim name script and using real live blockchain data and am confused about lbrycrd output:
    ```"asm": "OP_CLAIM_NAME<PHONE_NUMBER> 080110011a7808011230080410011a084d616361726f6e6922002a003214416c6c207269676874732072657365727665642e38004a0052005a001a42080110011a30add80aaf02559ba09853636a0658c42b727cb5bb4ba8acedb4b7fe656065a47a31878dbf9912135ddb9e13806cc1479d220a696d6167652f6a7065672a5c080110031a404180cc0fa4d3839ee29cca866baed25fafb43fca1eb3b608ee889d351d3573d042c7b83e2e643db0d8e062a04e6e9ae6b90540a2f95fe28638d0f18af4361a1c2214f73de93f4299fb32c32f949e02198a8e91101abd OP_2DROP OP_DROP OP_DUP OP_HASH160 be16e4b0f9bd8f6d47d02b3a887049c36d3b84cb OP_EQUALVERIFY OP_CHECKSIG",
    "hex": "b504636174734cdc080110011a7808011230080410011a084d616361726f6e6922002a003214416c6c207269676874732072657365727665642e38004a0052005a001a42080110011a30add80aaf02559ba09853636a0658c42b727cb5bb4ba8acedb4b7fe656065a47a31878dbf9912135ddb9e13806cc1479d220a696d6167652f6a7065672a5c080110031a404180cc0fa4d3839ee29cca866baed25fafb43fca1eb3b608ee889d351d3573d042c7b83e2e643db0d8e062a04e6e9ae6b90540a2f95fe28638d0f18af4361a1c2214f73de93f4299fb32c32f949e02198a8e91101abd6d7576a914be16e4b0f9bd8f6d47d02b3a887049c36d3b84cb88ac",```

looking at the hex: b5 is correct for OP_CLAIM_NAME, then it's 04 which is correct for length of upcoming string, consuming the next 4 bytes (8 in hex) gives us cats:
'cats'```

so... wtf is `1937006947` as returned by lbrycrd as the claim name?
it's not hex and it's not ascii

### Acceptance Criteria
1.
2.
3.

### Definition of Done
- [ ]  Tested against acceptance criteria
- [ ] Tested against the assumptions of the user story
- [ ] The project builds without errors
- [ ] Unit tests are written and passing
- [ ] Tests on devices/browsers listed in the issue have passed
- [ ] QA performed & issues resolved
- [ ] Refactoring completed
- [ ] Any configuration or build changes documented
- [ ] Documentation updated
- [ ] Peer Code Review performed

Agreed with the following:
b5 is OP_CLAIM_NAME
04 is 4 bytes or 63617473
63617473 is "cats"
4c is OP_PUSHDATA1
dc is 220 bytes or the claim
I don't process the ASM, but the raw data from lbrycrd for the chainquery app. Below is a screenshot of all claims by the name "cats". Not sure if this is helpful to you, but all the ASMs have this problem.

We can delete this if statement: https://github.com/lbryio/lbrycrd/blame/270307a29070a4c10095528e232ad0f8e251ec5a/src/core_write.cpp#L90
Since for our use case it is better to treat data of any size as a hex string

Are any new unit tests necessary for this, except those already in existence: https://github.com/lbryio/lbrycrd/blob/master/src/test/script_tests.cpp#L1067 ?

We can delete this if statement: https://github.com/lbryio/lbrycrd/blame/270307a29070a4c10095528e232ad0f8e251ec5a/src/core_write.cpp#L90

@kaykurokawa I'm not saying I strongly disagree here, since it's just a string representation, but I also think it can be easily (and consistently) handled upstream since it's the same data.
#include <stdio.h>
#include <arpa/inet.h>

int main(int argc, char** argv)
{
    printf("%d, %x, %x\n",<PHONE_NUMBER>,<PHONE_NUMBER>, ntohl(1937006947));
    return 0;
}

This prints out<PHONE_NUMBER>, 73746163, 63617473, which is what you'd expect.

@kaykurokawa What is the status of this issue? I

@mirgee provided https://github.com/lbryio/lbrycrd/pull/172 for a fix if someone wants to use it.
But to err on the safe side, it shall not be merged in case some applications might expect the decode function to behave as it does in Bitcoin.
A proper solution should detect to see if data to print is part of a claim transaction, and always treat that data as hex if that is the case.
No one is depending on this feature so this is not urgent.

fixed via cherry-pick


Allocate off-heap memory instead of on-heap memory from protobuf for Netty

It's meaningless to allocate direct memory for hazelcast currently because it will copy all bytes from buffer. So we need to reactor its IO logic first.


[BUG] AttributeError: module 'tensorflow.keras.initializers' has no attribute 'truncated_normal'\n in multinomial_vae.py

Description
Based on the Global Settings and Imports in the example notebook for multinomial_vae, it requires tensorflow==2.2.0-rc1 and keras==2.3.1. After I installed these two libraries and ran the code, I got AttributeError: module 'tensorflow.keras.initializers' has no attribute 'truncated_normal'\n when running multinomial_vae.py. According to Tensorflow 2.2 documentation, there isn't a class called truncated_normal  but there is one named TruncatedNormal.
How do we replicate the issue?
Running the notebook would probably encounter this error.
Expected behavior (i.e. solution)
Change truncated_normal  to TruncatedNormal in here and here should resolve this problem.

this PR should fix your problem https://github.com/microsoft/recommenders/pull/1565


avoid expensive spatial intersection over features that will never be relevant to the project [MARXAN-1744]

https://vizzuality.atlassian.net/browse/MARXAN-1744

@aagm as I was adding a small filter to explicitly avoid having split features (which following Ángel's recent work on split are now "first-class" features in (apidb).features) in lists of features (because of many reasons that would imply wide-reaching changes across the code base), I also noticed an old tech-debt note by Kamil, and this PR is an attempt to at least address the low-hanging fruits of his notes (which I have, accordingly, removed from the debt notes, while adding more thoughts for possible future improvements).
Basically until now we were first getting the list of all the distinct featureIds of any (geodb)features_data that intersects the project's bbox and then checking which ones were either for platform-wide features or project-specific features for the project being queried.
With this proposed change, we now first check which featureIds may be relevant at all (so, platform-wide or project-specific) and then we limit the bbox intersection check to only the features_data rows that belong to these features, which may keep query complexity kinda O(prn) (with prn being the number of features_data rows potentially relevant to the project, irrespective of their bbox) rather than P(pln) (with pln being the number of features_data rows _across the whole platform, irrespective of their public status or parent project).
So basically I expect this change not to make much of a difference right now when pln ≈ prn, but I hope it can slow down query time collapse when pln ≪ prn.


pull request for e2e test at 11/12/2016 02:45:08

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

Details

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Cross-project IntelliSense doesn't work properly

This repro involves two projects, named foo and baz.
Here is the directory tree layout:
ptvs_bug/
├── foo/
│  ├── __init__.py
│  └── bar/
│      ├── __init__.py
│      └── MyClass.py
└──baz/
   └── baz.py

I have created one project for foo using File -> New -> Projects -> From Existing Python Code
I have then created another project for baz using the same workflow.
I right clicked on the Search Paths for baz and manually pointed to ptvs_bug, which ultimately gets resolved to the relative path ...
Here is the code for each of these files.
# ptvs_bug/foo/__init__.py
# This file is empty.

# ptvs_bug/foo/bar/__init__.py

import MyClass

my_class = MyClass.TheClass()
my_integer = 7

# ptvs_bug/foo/bar/MyClass.py
class TheClass(object):
    pass

# ptvs_bug/baz/baz.py
import sys
print(sys.path)

from foo.bar import my_integer
from foo.bar import my_class

x = my_integer
x = my_class
pass

In a Python 2.7 environment, the two imports in baz.py get squigglies.  I can get rid of them by adding from __future__ import absolute_import, but I still get <unknown type> when hovering on my_integer and my_class.
In Python 3.6, the behavior is the same as using a 2.7 environment and using absolute_import.
All of the search paths are correct, because the program runs just fine, and the print(sys.path) line confirms that the correct paths are indeed present.
This may be related to Issue #3159, but it's not entirely clear, and the poster there did not provide a reproducer, which I have here.
I ran Diagnostics which you can see here, and I notice some exceptions that look might suspicious.  For example:
[10/20/2017 16:34:34] AnalysisOperationFailed: System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.PythonTools.Analysis.LocationInfo.GetHashCode()
   at Microsoft.PythonTools.Analysis.AnalysisVariable.GetHashCode()
   at System.Collections.Generic.ObjectEqualityComparer`1.GetHashCode(T obj)
   at System.Linq.Set`1.InternalGetHashCode(TElement value)
   at System.Linq.Set`1.Find(TElement value, Boolean add)
   at System.Linq.Enumerable.<DistinctIterator>d__63`1.MoveNext()
   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
   at Microsoft.PythonTools.Intellisense.OutOfProcProjectAnalyzer.IsMissingImport(IsMissingImportRequest request)
   at Microsoft.PythonTools.Intellisense.OutOfProcProjectAnalyzer.<RequestHandler>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PythonTools.Ipc.Json.Connection.<ProcessRequest>d__29.MoveNext()

Hopefully this is enough information to help track it down.

This is using 15.4, by the way.

I suspect the issue may be the same as #3159 (which I'm about to test specifically for this - waiting for machines to wake up after the weekend right now :) ).
That error is also helpful, but very unlikely to be the cause. But I'll fix it too!

I've confirmed that this issue is fixed, so our next update to 15.4 should include it. Thanks!

Is there any way to get a preview build?  I trust that you did indeed fix it, but my real project is much larger and more complicated than the minimal repro I came up with for this bug report.  Happy to test on a larger codebase for additional confirmation if there's an easy way to do it.  Otherwise I'll cross my fingers and wait :)

Afraid not. We decided to "skip" the current preview release and focus our efforts on the next one, which allows us to do bigger pieces of work. We also plan to update the current Preview release with this bugfix (or else the 15.5 release would also have the same bug...), but it's not clear whether that will be released before the next update to the main release.
Alternatively, if you can build PTVS yourself, you should be able to drop in the DLLs to their install directories and test them that way. You'll need to run our registry script to disable strong name verification (part of the build instructions on our wiki), and it's a very manual (and unsupported) install step. But it works. Our v3.2 branch has the fix - master is significantly less stable right now.


Remove leftover broker plugin files

It seems that some broker plugin files were reintroduced in CAF 0.18.6 upgrade.

Thanks!

Sorry for breaking it in the first place

Sorry for breaking it in the first place

No worries, I was surprised we didn't break more constantly rebasing a 250+ file PR.


Sign urls in search rest service again

closes #5957
Since the search rest service doesnt sign urls anymore, the engage player wont work when signing is required for all urls. This PR adds url signing again to the search rest service and therefore reintroduces the sign parameter, having the default to true.
Previous PR that falsely targeted develop: https://github.com/opencast/opencast/pull/6082

Ah, just when I wanted to hit merge :D
Will do a quick review and see that this makes it into 16.3 after CI is done.


Update rules and procedure pdf

Overview
This branch updates the rules and procedures pdf on the About Us page from an external link to a locally hosted pdf. It also merges a couple of the the sections on the same page

Closes #1097
Closes #1098

Testing Instructions

Head to the About Us page
Confirm that the "Board Room Rules" and "Rules & Procedures" sections have been merged
Click the link that reads "Read about all Metro Rules & Procedures."
Confirm that a locally hosted pdf opens, identical to the one described in the issue

enormously agree! it's such a time saver


Remove Arc from LogicalPlan

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Related to #4627, the current representation of LogicalPlan contains Arc<LogicalPlan> at various points, whilst this does reduce the cost of copying a LogicalPlan tree, it:

Complicates rewrites by necessitating clones
Results in double-boxing - e.g. Vec<Arc<LogicalPlan>>
Permits cycles and all the excitement that would entail
Marginal overhead from additional atomics
Unidiomatic is perhaps too strong, but it is strange for a tree datastructure to have shared ownership

Describe the solution you'd like
I would like to remove the Arc, replacing with Box where necessary. Methods that currently take Arc<LogicalPlan> should be updated to take LogicalPlan.
Describe alternatives you've considered
Additional context
This likely wants to wait until we are cloning LogicalPlan less frequently

I believe @mingmwang  and @jackwener  have noted this in the past -- the idea is good to me

Hope to this change😍, it is very meaningful to optimizer.

If we can remove Arc<LogicalPlan> and use LogicalPlan, wen can use pattern-match to match subtree pattern like:
match projection-filter
LogicalPlan::Projection(Projection{LogicalPlan::Filter, ..})

How would OptimizerRule look after the change?
Currently we have:
/// Try and rewrite `plan` to an optimized form, returning None if the plan cannot be
/// optimized by this rule.
fn try_optimize(
    &self,
    plan: &LogicalPlan,
    config: &dyn OptimizerConfig,
) -> Result<Option<LogicalPlan>>;

With the current try_optimize signature, lack of Arc<LogicalPlan> would require to clone whole non-optimised subbranches.

How would OptimizerRule look after the change?

Maybe we could change the signature to something like
enum OptimizedPlan {
  // Optimizer did not make any changes to the original input pla
  NoChange(LogicalPlan),
  /// Optimizer rewrote the original plan
  Rewritten(LogicalPlan),
}

/// Try and rewrite plan to an optimized form
fn try_optimize(
&self,
plan: &LogicalPlan,
config: &dyn OptimizerConfig,
) -> Result;

I think you would want to make try_optimize take ownership not a borrow, and then return it

I think you would want to make try_optimize take ownership not a borrow, and then return it

I think there are cases (like deciding when a fixed point is reached) where the caller wants to distinguish between no more optimization and a new plan.
However, now that LogicalPlan supports PartialEq I think maybe we could just use that to check if any changes were made
https://github.com/apache/arrow-datafusion/blob/c37ddf72ec539bd39cce0dd4ff38db2e36ddb55f/datafusion/expr/src/logical_plan/plan.rs#L52
So the signature maybe could be
/// Try and rewrite `plan` to an optimized form
fn try_optimize(
    &self,
    plan: LogicalPlan,
    config: &dyn OptimizerConfig,
) -> Result<LogicalPlan>;

🤔

To compare a new logical plan with the old one, we need to have both plans in the memory.
Without Arc<...>, it requires to have always doubled RAM usage for plans. With Arc<...> a slightly less? 🤔

However, now that LogicalPlan supports PartialEq I think maybe we could just use that to check if any changes were made

This is not a particularly cheap operation, involving a lot of string comparisons. I think having the return value indicate if changes have been made as in your original example makes sense to me.
My point was if we remove the Arc we need to be careful to move LogicalPlan and avoid cloning, as any clone is then a deep clone of the entire tree, and so we need to pass in an owned value

I think having the return value indicate if changes have been made as in your original example makes sense to me.

At the first sight the idea seems to be compelling...
Nevertheless I'm quite pessimistic about the idea. 😵💫
The main reason are optimisations, which UNDO other optimisations!
(sorry for the long post! but it's core architecture stuff...)

Examples of cancelling optimisations
Example 1. Commutative optimisations
Some operations are commutative, like projection or limit - it is used in both PushDownProjection and PushDownLimit - but in a different directions (grep commute in these files).
So for some plans they will always give Some(new_plan). 😕
Example 2. Undoing inside of an optimisation
Inside PushDownLimit we have:

Limit A -> Projection -> Limit B
Added a limit after the projection: Limit A -> Projection -> Limit C -> Limit B
Merge of the Limit C and Limit B in ANOTHER invocation of try_optimize: Limit A -> Projection -> Limit B

We have many invocations of try_optimize due to apply_order option.
The point is that for a fixed point (merge of Limit C + Limit B is Limit B) PushDownLimit will always yield Some(...).

Theoretical pain
Let's look at the issue formally... 😎
Consider small changes Δ_1, Δ_2, ... Δ_n - some signed integers.
The total change is:
Δ_all = Δ_1 + Δ_2 + ... + Δ_n

So Δ_all ≠ 0   implies   Δ_i ≠ 0 for some i.
The premise of Option<Plan> is that the implication holds in the another direction - which is NOT the case!
Just give Δ_1 = 1, Δ_2 = -1, Δ_3 = 0... (Δ_2 cancels changes from Δ_1!)
Alternatives?
Let's look again at the implication - how can we use it?
Δ_all ≠ 0   implies   Δ_i ≠ 0 for some i.
I would consider to use some stats about the tree - as a kind of heuristics. For example: number of nodes in the tree.
Each optimization could return (LogicalPlan, Δ of number of nodes). If sum of all Δ of number of nodes is nonzero - then we know the tree has changed.
I guess there could be other useful stats, like ∑ (node_type * node depth).

https://github.com/apache/arrow-datafusion/pull/5623 from @mslapek  is a nice step towards this goal, I think

To add a counter point to this change -- without sub-tree sharing, and in the presence of CTEs, LogicalPlan trees would be exponential in the size of the SQL query:
WITH
   A as (select 1 x),
   B as (select * from A, A)
   C as (select * from B, B)
   D as (select * from C, C)
select * from D;

without sub-tree sharing

Is this something that is actually practicable? I would have thought the optimizer would simply ruin any effort to do this?

I'm not familiar with the current optimizer implementation details, but this is a problem that manifests way before the optimizer comes into play -- if we take away sub-tree sharing in LogicalPlan, then the SQL compiler would be forced to generate exponential trees right from the start. Whereas in the current setup, (properly) generated LP trees would always be linear in the size of the input query, and if it blows up in some later optimizer stage, I assume it shouldn't be too hard to optimize the optimizer.

Is this a problem? Is the memory usage of the plan representation a concern? This feels like a relatively niche optimisation for plans with repeated CTEs, that may perhaps be a touch premature?

Yes this is a very real problem. We see this kind of pattern in production warehouse queries fairly often. They're usually the result of some automated query composition, and can get quite big by themselves. Tacking on an exponential factor on top means the system will be completely unusable (i.e. upwards of an hour just to compile one query, without even invoking the optimizer).
It's not just about the memory footprint -- if your datastructure itself is exponential then that's basically your lower bound for performance, as a simple operation like clone() would take exponential time. In general, exponential blow ups in production systems are deal breakers IMO, and removing them should not be considered premature optimization.
All that is to say, if you plan to remove Arc<LogicalPlan> (which I'm neutral), then you'll have to replace it with some other mechanism for common subtree sharing.

:+1: I agree we should not regress any extant functionality in this space

if we take away sub-tree sharing in LogicalPlan, then the SQL compiler would be forced to generate exponential trees right from the start. Whereas in the current setup, (properly) generated LP trees would always be linear in the size of the input query, and if it blows up in some later optimizer stage, I assume it shouldn't be too hard to optimize the optimizer.

For what it is worth, @mustafasrepo  and I are working on something similar https://github.com/apache/arrow-datafusion/issues/8582 (in the physical plans now, any CTEs used more than once will be expanded out and the results not shared)

Note about clone to remove
ScalarSubqueryToJoin
https://github.com/apache/datafusion/blob/e65c3e919855c9977cf4d80c0630ee26b7fd03ee/datafusion/optimizer/src/scalar_subquery_to_join.rs#L153


Fix wrong link to img in README_template.MD

Before:

After:

In workflows, the name - Compile and release

Codecov Report

Merging #226 (5fd7a9e) into dev (64ce227) will decrease coverage by 7.78%.
The diff coverage is 65.64%.

@@            Coverage Diff             @@
##              dev     #226      +/-   ##
==========================================
- Coverage   56.73%   48.95%   -7.79%
==========================================
  Files          85       82       -3
  Lines        2799     2764      -35
  Branches      563      586      +23
==========================================
- Hits         1588     1353     -235
- Misses       1059     1271     +212
+ Partials      152      140      -12

Impacted Files
Coverage Δ

src/Backend/Items/spEnumMemberItem.ts
58.33% <0.00%> (-6.89%)
:arrow_down:

src/Backend/Items/spItems.ts
100.00% <ø> (ø)

src/Backend/Items/spTypedefItem.ts
66.66% <ø> (+1.44%)
:arrow_up:

src/Backend/spItemsPropertyGetters.ts
6.49% <0.00%> (-0.86%)
:arrow_down:

src/Commands/setFileAsMain.ts
22.22% <0.00%> (ø)

src/Misc/parseSMAPI.ts
52.38% <0.00%> (+18.17%)
:arrow_up:

src/Providers/Linter/parseSPCompErrors.ts
16.66% <0.00%> (ø)

src/Providers/spDocCompletions.ts
6.00% <0.00%> (-71.56%)
:arrow_down:

src/Providers/Completions/spCompletionsGetters.ts
12.50% <2.63%> (-20.36%)
:arrow_down:

src/Providers/spSymbolProvider.ts
51.72% <12.50%> (-13.50%)
:arrow_down:

... and 70 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Use context.registration instead of session id extension

The standard context property 'registration' is designed to keep track things like sessions. We should use that instead of a session extension.
Since this has to a UUID, the LMS would likely need to have a look up tables between session id and registration id. This has the added security benefit of not exposing the user's session id in statement data.
https://github.com/jlowe64/moodle-logstore_xapi/issues/61

The requirement to make it a UDD may be blocker in the one for now, so might need to stick to our current implementation for now.

An registration is not necessarily the same as a session. In our LMS, we use session to designate the websession while registration is the assignment (in our case). So I disagree with @garemoko in this case.


Bump pytorch dockerfile template

Issue #, if available: N/A
Description of changes: update PyTorch dockerfile template to 24.02.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Still draft or shall we merge?

Ready to review.


RFC: Topic Endpoint

Feature name
Interface Specification Enhancement

Author(s)
swiftyos<EMAIL_ADDRESS>

Updated
2023-11-02

Summary
Current agent interaction mechanisms are primarily task-oriented. They lack the conversational fluidity and persistent memory capabilities desired for more intuitive and less repetitive user engagements. This proposal introduces the "Topic Endpoint" concept to bridge this gap, facilitating more natural, chat-based interactions and enabling memory persistence across different tasks.
Motivation
The primary motivation is to enhance user experience by aligning agent interactions more closely with user expectations. Users anticipate a conversational engagement and a memory retention feature that saves them from providing the same information repetitively. By ensuring a persistent memory and a more natural interaction model, we aim to expedite task execution and enrich user-agent interaction.
Agent Builders Benefit

Multi-task Persistent Memory: Enable agents to remember context and information across multiple tasks, reducing the need for users to repeat information.
Natural Interactions: Allow users to interact with agents in a more conversational manner, without being bound strictly to task-oriented dialogues.
Ease of Development: Simplify the development process by not requiring overriding of the existing task concept to achieve the desired interaction model.

Design Proposal
This proposal recommends introducing new abstract entities and refining the interactions among existing entities within the system. Here are the key entities from an abstract perspective:

Topic: A persistent long-term concept, encapsulating a set of related tasks and interactions.
Interaction: A chat-like messaging mechanism allowing for back-and-forth communication with the topic, thus facilitating a more natural dialogue.
Task: Represents a task with a specific goal. Tasks are grouped under topics and can access shared memory within the topic.
Step: Denotes a specific step within a task, guiding the task towards its goal.
Artifact: Signifies a persistent resource space owned by an agent, wherein data relevant to a topic is stored and managed.

Interaction Flow

Topic Initiation: A user initiates a topic, setting the stage for a set of related tasks.
Interaction: The user engages in a chat-based interaction within the topic, providing necessary information and context.
Task Execution: Based on the interaction, tasks are created and executed in sequence or parallel, as appropriate.
Step Processing: Each task is broken down into steps, ensuring structured progress towards the goal.
Artifact Management: Artifacts are updated and managed throughout the interaction, retaining essential information for future reference.

sequenceDiagram
title: Interaction Flow among User, Topic, Task, and Step
participant User
participant Topic
participant Task
participant Step

User -> Topic: Initiate Topic
loop Interaction Loop
    User -> Topic: Chat-based Interaction
    Topic -> Task: Derive Task from Interaction
        loop Step Execution Loop
            User -> Step: Execute Step
            Step -> Task: Update Task State
            Step -> Step: Create Artifact
            Step -> Step: Update Step State
        end
    Topic -> User: Provide Task Completion Feedback
end

Detailed Design
The proposed transition in endpoint structure is poised to encapsulate tasks within higher-level entities known as topics, shifting from the existing endpoint /ap/v1/agent/tasks/{task_id} to a more organized format /ap/v2/topics/{topic_id}/tasks/{task_id}. Additionally, a new endpoint /ap/v2/topics/{topic_id}/interactions/{interaction_id} will be added to handle interactions within those topics in a more chat like manner. The agent verb is being dropped as it adds no value. This new structure aims to facilitate a more intuitive and organized approach to handling user interactions and task management.
Endpoint Specifications
Topics

Create a New Topic:

Endpoint: /ap/v2/topics
POST Method:

OperationId: createTopic
Summary: Create a new topic.
RequestBody:

Content: application/json

Responses:

'201': Successfully created a new topic.
'400': Bad request.

List Topics:

Endpoint: /ap/v2/topics
GET Method:

OperationId: listTopics
Summary: Retrieve a list of all topics.
Responses:

'200': Successfully retrieved list of topics.

Get a Specific Topic:

Endpoint: /ap/v2/topics/{topic_id}
GET Method:

OperationId: getTopic
Summary: Retrieve details of a specified topic.
Parameters:

topic_id

Responses:

'200': Successfully retrieved topic details.
'404': Topic not found.

Interactions

Create a New Interaction:

Endpoint: /ap/v2/topics/{topic_id}/interactions
POST Method:

OperationId: createInteraction
Summary: Create a new interaction within a specified topic.
Parameters:

topic_id

RequestBody:

Content: application/json

Responses:

'201': Successfully created a new interaction.
'400': Bad request.

List Interactions in a Topic:

Endpoint: /ap/v2/topics/{topic_id}/interactions
GET Method:

OperationId: listTopicInteractions
Summary: Retrieve a list of interactions for a specified topic.
Parameters:

topic_id

Responses:

'200': Successfully retrieved list of interactions.

Get a Specific Interaction in a Topic:

Endpoint: /ap/v2/topics/{topic_id}/interactions/{interaction_id}
GET Method:

OperationId: getTopicInteraction
Summary: Retrieve details of a specified interaction within a topic.
Parameters:

topic_id, interaction_id

Responses:

'200': Successfully retrieved interaction details.
'404': Interaction not found.

The design of these endpoints follows a RESTful approach, ensuring a clear and organized way to interact with topics, interactions, and tasks within the new v2 structure. Each endpoint provides specific functionalities, enabling clients to manage and retrieve information efficiently.
Certainly! Here are the requested sections tailored to fit the context of your proposal on transitioning to a new endpoint structure:
Alternatives Considered
The principal alternative deliberated is retaining the current endpoint structure /ap/v1/agent/tasks/{task_id}/steps without migrating to the hierarchical structure proposed. However, this alternative falls short in addressing the emerging need for a shared memory framework and the ability to handle chat-like interactions which are imperative for spawning tasks in a more intuitive and natural manner. The current flat structure may continue to pose challenges in efficiently managing and retrieving data as the system scales.
Note on Plugin Entities
It's important to emphasize that adding plugin entities to the interface is beyond the scope of this proposal. The focus here is on enhancing the clarity of the existing interface specification and addressing issues related to entity ownership and state changes.
Compatibility
The design proposal is crafted with backward compatibility in mind to ensure a smooth transition for existing systems. It's crucial to create comprehensive documentation and guidelines to aid in the implementation of the updated endpoint structure. Ensuring compatibility with other integral components of the system, such as SDK and Client SDK, is also paramount. Adequate checks and balances need to be put in place to ascertain that the transition to the new endpoint structure /ap/v2/topics/{topic_id}/tasks/{task_id} and /ap/v2/topics/{topic_id}/interactions/{interaction_id}does not disrupt the existing functionalities while paving the way for enhanced user interactions and data organization.

Maybe we should be calling this Threads now :)

Related: #44

Can you attend a meeting the Agent protocol meeting on the 12th to discuss this?


Fix GitHub spelling

Just a small typo fix Github -> GitHub.

@rvema - Any chance this small PR could get merged soon?

verbiage changes need to be passed through a team. Can you let us know what is the change?

Hi @rvema - Thanks for the reply. I'm not sure what you mean by "verbiage changes" .. As you can see in the diff, all this does is fix a common typo and changes Github to GitHub. Nothing else changed.
I just rebased the branch.

approved and merged


How to Mock getDestination for Unit Testing Java Methods with HTTP Requests?

Hi Team,
I’m working on unit testing a Java method that interacts with external HTTP destinations and performs HTTP requests. I’m having difficulty covering the method with JUnit tests due to its dependencies on external services.
Here is the method I need to test:
import static com.sap.cloud.sdk.cloudplatform.connectivity.DestinationAccessor.getDestination;
public String getResponseAsString(String path) {
HttpDestinationProperties httpDestination = getDestination(destinationName()).asHttp();
HttpClient client = getHttpClient(httpDestination);
try {
String requestUrl = httpDestination.getUri() +            HttpClientUtils.replaceSpecialSymbolsForIpSystem(path);
log.info("GET response as a string: {} ", requestUrl);
    return client.execute(new HttpGet(requestUrl), getResponseHandler());
} catch (IOException e) {
    log.error(CONNECTION_ABORTED, e.getMessage());
}

return EMPTY;

}
My challenges:
Mocking getDestination(destinationName()).asHttp(): How can I mock the destination and its properties?
What I’ve tried:
I attempted to use Mockito for mocking, but I'm unsure how to properly mock the getDestination and HttpClient methods.
This junits throws error: Destination Access exception: failed to get destination
I have raised the question in stackoverflow: https://stackoverflow.com/questions/78929088/how-to-mock-getdestination-for-unit-testing-java-methods-with-http-requests

Hi @Jagan1002, this is the cloud sdk for JavaScript, if you have any Java related question, raise them with the Java SDK.


Backporting try_init

Signed-off-by: AlexMikhalev<EMAIL_ADDRESS>

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Allow users to target specific tabs as closable, support jquery no conflict mode, and allow option to hide tabs on close instead of removing them from the DOM

preeety sure this isn't going to be merged. closing


[ITensors] [ENHANCEMENT] Support indexing notation A["Up"]

Codecov Report

Merging #839 (cba96a2) into main (7d7a420) will decrease coverage by 2.97%.
The diff coverage is 100.00%.

:exclamation: Current head cba96a2 differs from pull request most recent head 9a58cce. Consider uploading reports for the commit 9a58cce to get more accurate results

@@            Coverage Diff             @@
##             main     #839      +/-   ##
==========================================
- Coverage   76.01%   73.03%   -2.98%
==========================================
  Files          67       67
  Lines        7570     6313    -1257
==========================================
- Hits         5754     4611    -1143
+ Misses       1816     1702     -114

Impacted Files
Coverage Δ

src/itensor.jl
84.25% <100.00%> (-1.46%)
:arrow_down:

src/broadcast.jl
60.16% <0.00%> (-26.73%)
:arrow_down:

src/qn/qnindexset.jl
86.66% <0.00%> (-13.34%)
:arrow_down:

src/physics/site_types/tj.jl
65.82% <0.00%> (-8.98%)
:arrow_down:

src/indexset.jl
76.95% <0.00%> (-7.21%)
:arrow_down:

src/lastval.jl
57.14% <0.00%> (-7.15%)
:arrow_down:

src/physics/sitetype.jl
87.24% <0.00%> (-6.40%)
:arrow_down:

src/global_variables.jl
85.29% <0.00%> (-5.82%)
:arrow_down:

src/LazyApply/LazyApply.jl
61.53% <0.00%> (-5.64%)
:arrow_down:

src/ITensors.jl
25.00% <0.00%> (-5.00%)
:arrow_down:

... and 53 more

Continue to review full report at Codecov.

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


Mail.new(string) calls force_encoding on input

commit c7818a95f9f9fddc675f75452ea5000c46c30d94 calls force_encoding on input strings, leading to strange behavior like this:
str.encoding
# => 'UTF-8'
Mail.new(str)
str.encoding
# => 'ASCII-8BIT'

to_crlf makes a copy of the string anyway; I think force_encoding should get called on the copy since we got a surprise Encoding::UndefinedConversionError later on in our app.

Fixed by #615


fix fix check failed in StatefulOperator

Proposed changes
ix
F20240324 11:48:03.674883 55270 block.cpp:703] Check failed: d.column->use_count() == 1 (2 vs. 1)  , [k1, 2], [k2, 2]
*** Check failure stack trace: ***
    @     0x55df632ea216  google::LogMessageFatal::~LogMessageFatal()
    @     0x55df4a348f3c  doris::vectorized::Block::clear_column_data()
    @     0x55df618c09b1  doris::pipeline::StatefulOperator<>::get_block()
    @     0x55df62a721cf  doris::pipeline::PipelineTask::execute()
    @     0x55df62f89be7  doris::pipeline::TaskScheduler::_do_work()
    @     0x55df3a704b4d  doris::ThreadPool::dispatch_thread()
    @     0x55df3a6e26c9  doris::Thread::supervise_thread()
    @     0x7f9e03460609  start_thread

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Cast MongoCursor result to Collection of Model

Hi, I want to know if there is a way to cast a Mongo Cursor instance from a raw query in to  a Collection of Model.
DB::collection('test')->raw()->aggregate(             [                 ['$match' => ["status" => 'published' ]]             ]         );

I saw the method  toArray(); that cast  Mongo Cursor  instance into an array
DB::collection('test')->raw()->aggregate(             [                 ['$match' => ["status" => 'published' ]]             ]         )->toArray();

So now I need to cast each BSONDocument to a Model.
I want know if there is an efficiente way to do so. I think this is exactly what the package does under the hood
Thanks

I think that PR can will resolve this issue


Can't do a wildcard read for all tables

Currently, the shell does not allow to construct and send wildcard reads for all tables (table_id = 0, spec).
Examples:
P4Runtime sh >>> te = TableEntry()
Please provide name for table

P4Runtime sh >>> te = table_entry[""]
table '' does not exist

P4Runtime sh >>> te = table_entry[]
  File "<ipython-input-11-f60488650eb6>", line 1
    te = table_entry[]
                     ^
SyntaxError: invalid syntax

Hi,
to list all the tables type tables within the shell.


Locate ATLAS on RHEL/CentOS 7

For whatever reason, the standard yum-installed ATLAS libraries were renamed for RHEL/CentOS 7.0.

Sweet, thanks for the patch.

Just an update:  this works, but isn't quite right.  CentOS 7 ATLAS implements the full BLAS/LAPACK functionality in two separate libraries: libsatlas (single-threaded), libtatlas (mutlithreaded).  My changes link to both libraries, but libtaltas is first, so the linker discards the symbols from libsatlas.  There's a big thread at https://fedorahosted.org/fpc/ticket/352 describing the current mess in Fedora between netlib/ATLAS/OpenBLAS library scemes.

Ha, ok.  As long as it works then that's fine.


feat: Configurable stale/close workflow

Feature Request
Describe the Feature Request
I think the project should be more transparent about a) including this specific workflow, and b) allowing it to be more easily configurable.
My projects are mostly pretty small. If I get contributions, I'm willing to give a long time for contributors to respond to feedback, and I might never close an issue, even if it hasn't had activity, in case someone is willing to take it up at some point in the future. (I don't mind issues being closed so much as them being locked to new comments.)
PR https://github.com/dec0dOS/amazing-github-template/pull/2 is actually a good example. For your project it may make sense to mark it as stale after 30 days, and close it a week later, but for me that would be too quick. I don't have many contributors, and I want to give them more leeway.
If this is added to an existing project, maintainers might not realize this is one of the workflows being enabled, and/or might not realize the timeline that's now being enforced.
I realize one can go in and just remove the workflow or change the days-before-stale or days-before-close values, but this is about surfacing something that could be a surprising or disruptive change for a small project.
Describe Preferred Solution

Assuming you don't want to inquire in the setup process about every single workflow, consider making this one a special case and allowing people to enable/disable it on setup.

If enabled, inquire in the setup what the values of days-before-stale and days-before-close should be.

Note in the project documentation how to remove or change this workflow (and maybe workflows in general) if it isn't important to a project.

Describe Alternatives
Just do number 3 above. To me that would be sub-optimal, but better than not mentioning it at all.
Related Code

Additional Context
N/A
If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

[x] Yes
[ ] No

Hey, @rootwork, that is a great suggestion.
I've been struggling with too early stale trigger with my another repo.
It should be disabled by default by the cookiecutter flag.


Upgrade JLine

It seems JLine has newer version (3.21.0) than the one mentioned here.
I hope there is a delivery with the latest from both libraries, since there are still errors with picocli-shell-jline3 4.6.1 and jline 3.21.0

Can you be more specific? "there are still errors" does not tell me what the problem is, or how to reproduce it.

@asashour Is this still an issue? Can you provide more details about the issue and how to reproduce it?

I had a compilation error, but it seems with 4.6.2, it is fine.
Thanks.


Defining a method named "metadata" breaks mongoid

The following method definition in your model:
...
end

will result in this error when trying to set the field to a Hash object:
```    undefined method path' for {}:Hash (eval):2:in method_missing'
(eval):2:in method_missing' .../gems/mongoid-2.3.4/lib/mongoid/atomic.rb:210:in atomic_paths'
.../gems/mongoid-2.3.4/lib/mongoid/atomic.rb:148:in atomic_selector' .../gems/mongoid-2.3.4/lib/mongoid/persistence/operations.rb:117:in selector'

For example, with this code:
```doc = Document.first
doc.metadata = {:one => 1} # or doc.update_attribute...
doc.save

Hmmm, that should have raised an InvalidField exception... I'll flag for 2.4.0

Same problem. Isn't 'metadata' a quite common name to be reserved? I noticed the problem just because moving to mongoid 2.2 broke my application due to a 'metadata' field in a 'Page' model.
I've solved my problem renaming the field, so, its just an answer.

I guess I can rename the internals to _metadata, since you're right it would be common... I just need to look at all the gems out there that may be hooking into that and either submit pull requests to them or warn them, and it would be a 3.0 change since it is API breaking... So 2.4.x would have to have the temporary fix of raising the error.


Add MQTT source/destination

This needs some documentation to show what config options are needed, but it allows you to subscribe to an MQTT topic to receive messages or send messages to a topic.

Any reason we shouldn't merge this @harpesichord ?

I was going to consider Alan's points. I'll probably look at it again
Sunday evening and then maybe we can merge Sunday night or Monday morning.
On Fri, Aug 11, 2023, 7:03 PM Evan J Johnson @.***>
wrote:

Any reason we shouldn't merge this @harpesichord
https://github.com/harpesichord ?
—
Reply to this email directly, view it on GitHub
https://github.com/runreveal/kawa/pull/22#issuecomment-1675498824, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABDRAUI2JGHNNSZOGJDUD2LXU2237ANCNFSM6AAAAAA3GIMMLM
.
You are receiving this because you were mentioned.Message ID:
@.***>

@abraithwaite Can you check this again, make sure I followed your new pattern correctly.


Workers are not releasing memory after the task is completed.

This is unfortunately how the multiprocessing works; as long as the workers are active they will claim extra memory for tasks they run. Rather than closing and respawning workers after each task, there is a recycle setting (https://django-q.readthedocs.io/en/latest/configure.html#recycle) that you can tune to recycle workers after a set amount of tasks.  Or you can set a max resident set size to have the workers recycle after they claimed a certain amount of memory (https://django-q.readthedocs.io/en/latest/configure.html#max-rss)


Style Guidelines for CONTRIBUTING.md

Start developing style guidelines for the project. Ideally based of some existing style guidelines, which are extended for this particularly use case.

return statements
project.j2objcConfig access and @Input and @Output connections
project.with

Here's the standard Groovy style guide:
http://www.groovy-lang.org/style-guide.html
Since we are a 100% groovy project, I think we should stick as closely as we can to them.  A mixed Java/Groovy style I think will be even more confusing.

Looks good, we should follow this and then add extra stuff specific to Gradle. I'll work on that.

Ah good point.

Suggest we say that our style is Groovy style guide, and where it does not specify and does not conflict, back-off to Google Java style guide:
https://google-styleguide.googlecode.com/svn/trunk/javaguide.html
Also, we need to make a decision on top-level method calls in statements.  We are very inconsistent between java.call(arg) style and groovy.call arg style.

I personally prefer parentheses as I find it more familiar. It sounds like the Groovy Style Guide isn't clear on this but I suspect it would make it easier for other engineers contributing.
What's your thoughts on this @advayDev1?

I'm torn.  I'm huge on consistency so that style things become more mechanical and less subject to reviewer dispute.  If we're going to split into parens and no-parnes, I'd suggest the following rules:

If the statement is solely a DSL/property setting method (ex. 'translateArgs in j2objcConfig'), do not use parentheses on the top-level method.
If the statement is a logging method of the form logger.LEVEL or log.LEVEL, do not use parentheses on the top-level method.
Otherwise, always use parentheses.

Thoughts?


Rendering of railways at higher zoom levels

What's your idea for a cool feature that would help you use OHM better.
Currently railways disappear at zoom=12 while secondary highways disappear at zoom=9 and primary highways at zoom=7. Historically railways are (and sometimes still are) as important as primary highways and definitely more important than secondary highways. I think railway should stay until at least zoom=8 to better get a picture of an area and what major traffic connections were at the time.
Current workarounds
Is there any way to meet this need using a workaround or "hack" right now? Not really
Additional info
See: https://www.openhistoricalmap.org/#map=11/47.5585/9.1114&layers=O
for example:
no railway for high zoom:

only at this zoom level 13 are the railways drawn:

@danrademacher @tsinn currently all transport features are part of a single vector tile layer, that may be limiting us from more flexible way to surface features at different zoom levels. Let me know if you think we can't solve this in the style, I'd be happy split rail lines into a separate layer.

All set, @geohacker - we can symbolize easily on our end in Maputnik. We will go from minzoom of 12 to minzoom of 9.

  I have been thinking about requesting something similar. Though I would change the request to be (railway=rail and usage=main) to be zoom level 7 and (railway=rail and usage=branch) to be zoom level 10 all other rails can come in on zoom level 12.  The only thing is that railway=narrow_gauge will also need to be added along side railway=rail.

@geohacker, it appears as though the railway features within the transport layer are only visible in the tiles at >=z11.
To satisfy @natfoot's request, would it be possible to have them rendered from z7? At that point, we will be able to take over with styling.

@tsinn  could you try testing the railways at zoom 7 ? I've updated that in the staging version https://vtiles-staging.openhistoricalmap.org/#8.22/47.765/-121.979

Edited so that the railroad cross ticks change from z6 (narrow) - z10 (wide).

Done, Closing this ticket!


Housing Prices Prediction Project added

Description
As referenced in #52  I have completed it using the ANN which is giving high accuracy.
Fixes # (issue)
Type of change

New feature (non-breaking change which adds functionality)

Add resources to readme
add screenshots to folder

Refer https://github.com/garimasingh128/awesome-python-projects/pull/32


postgresql_17: fix build

Closes #354497
See https://www.postgresql.org/message-id/ba8e1bc0-8a99-45b7-8397-3f2e94415e03%40suse.de for context.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] 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
[ ] 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.

Force of habit, we have a team now :upside_down_face:


Use MNE-Python 1.0.0 stable

cc @larsoner
Will fail until the new packages are on the CDN

FYI I've put this in step 17 in https://github.com/mne-tools/mne-installers/pull/105

... I mean https://github.com/mne-tools/mne-python/wiki/How-to-make-a-release

@hoechenberger I say we merge this once green so that we have some working installers, then update the URLs on the homepage to use them. That takes away any time pressure from release.
Then we merge https://github.com/conda-forge/mne-feedstock/pull/88, rebuild in another PR here, and iterate until they work on all platforms. Once they do, we can update the installer pages again. WDYT?

Yes +100 for me

I'm off for the rest of the day, do what you think is best. We'll send out the announcement tomorow, right? @agramfort

I tested the draft pre10 on all three platforms and things appeared to work, so I cut a new v1.0.0 non-draft, non-prerelease version (+tag). Once the assets show up, I'll update the installation instructions with [circle deploy] for both. Then I think things will be all set for release announcements (I edited the google doc @agramfort) tomorrow

Amazing. Thanks so much @larsoner
I'm also feeling comfortable with tuning and improving the installer whenever an idea or an issue pops up. In the worst case, users can always go back to using our conda install instructions if the installer doesn't work in their system until we provide a fix.


Add more CNN networks to generate encodings

Apart from the current mobilenetv3, allow users to experiment with other pretrained CNN models. Possibly allowing user to add custom models too.

Addressed by #190 and merged in release 0.3.2.


[SPIKE] Performance optimization

Analyze https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fcapybara.storefrontcloud.io%2Fwomen%2Ftops-women%2Ftops-21&tab=mobile
Split into tasks.

We need to get an 80-90 score minimum. Performance over features: it's ok to remove wishlist, compare and other minor modules at all to optimize the bundle size, etc.
There is a lot of optimization works in VSF itself (develop branch) so feel free to deploy the newest VSF version with the theme prior to tests

Maybe we can extend searchAdapter or make new module that will wait for idle time and then fetch those resources:

This can reduce Time to Interactive by 1s

Also there are loaded banners files for other languages, but this is probably more related to core.

Our goal is to achieve Pagespeed 80+


Adjust warnings from target_kind.cc messages to debug level

This change moves recently introduced warning messages on target_kind.cc to be shown only in debug mode. The reason is because anytime we want to iterate over the list of targets they will be shown, making it overly verbose, e.g. in tvmc.
$ tvmc --version
[12:30:02] (long path)/src/target/target_kind.cc:217: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[12:30:02] (long path)/src/target/target_kind.cc:231: Unable to detect ROCm version, assuming >= 3.5
[12:30:02] (long path)/src/target/target_kind.cc:217: Unable to detect ROCm compute arch, default to "-mcpu=gfx900" instead
[12:30:02] (long path)/src/target/target_kind.cc:231: Unable to detect ROCm version, assuming >= 3.5
0.9.dev0
...

cc @junrushao1994 @Leo-arm @gromero for reviews

Thanks @leandron for bringing it up! The error message is only supposed to appear when user doesn’t supply arch information, and it could not be detected in our local environment- which means either the local environment is not set up properly, or it’s cross compilation without a clear target arch. Either case looks suspicious, and thus we think it’s necessary to provide error message explicitly.
Would you like to elaborate when the warning looks unnecessarily verbose? Is it in the CI environment?

Thanks @leandron for bringing it up! The error message is only supposed to appear when user doesn’t supply arch information, and it could not be detected in our local environment- which means either the local environment is not set up properly, or it’s cross compilation without a clear target arch. Either case looks suspicious, and thus we think it’s necessary to provide error message explicitly.
Would you like to elaborate when the warning looks unnecessarily verbose? Is it in the CI environment?

Sure, if you see the example I provide in the initial message, it is expected that some machines won’t have a Rocm and/or cuda version - they are optional dependencies anyway.
For those machines, the user will always see those warning messages, even when, for example, they would only want to target CPU with LLVM. This is what I meant by it being overly verbose, from the user point of view.
Perhaps we could make it more specific on when those messages are displayed, so that users see them when they are relevant in the context. I don’t have any proposal to solve that, but moving them to debug will make both the API and tvmc usage more clean.

Thank you @leandron for the explanation!

Sure, if you see the example I provide in the initial message, it is expected that some machines won’t have a Rocm and/or cuda version - they are optional dependencies anyway.
For those machines, the user will always see those warning messages, even when, for example, they would only want to target CPU with LLVM. This is what I meant by it being overly verbose, from the user point of view.

Yeah I agree. Those dependencies like cuda or rocm are optional, and creating cuda/rocm targets probably means cross-compilation - in this case, not giving specific arch version looks like a bit fishy :-) And I agree that likely users just want to generate code for CPU with LLVM.
I'm 100% supportive of improve warning messages for TVMC and the overall TVM stack, and probably I don't have all the context, so might ask some really dumb questions - Why do these warning messages pop up even if users are not doing anything wrong? Is that because does tvmc --version constructs some dummy targets?
Thanks a lot!

Why do these warning messages pop up even if users are not doing anything wrong? Is that because does tvmc --version constructs some dummy targets?

Yes, there are some dumb targets being created, as a way to collect the arguments for each target.
https://github.com/apache/tvm/blob/515fc88e71c8df94ed7bd6eae42103f34ac1f570/python/tvm/driver/tvmc/target.py#L47-L57
Any idea on how to solve the usability issue when creating these dummy targets?

Aha I got it now. Thanks @leandron for the explanation!
The problem could go away if we do not create dummy Targets in TVMC if users don't specify them explicitly, and to make this happen, we could improve the implementation of the API ListTargetKindOptions:
https://github.com/apache/tvm/blob/f32042f98b1948d7be468969d705acc44b9b1cbe/src/target/target_kind.cc#L52-L58
Right now it takes a TargetKind object and returns its key2vtype_ member. And to construct a TargetKind object, TVMC has to create dummy Targets and then extract its kind field.
https://github.com/apache/tvm/blob/515fc88e71c8df94ed7bd6eae42103f34ac1f570/python/tvm/driver/tvmc/target.py#L56
Alternatively, it's possible to avoid doing so by wrapping it with a method that takes a string:
Map<String, String> ListTargetKindOptions(const String& target_kind_name) {
  return TargetKindRegEntry::ListTargetKindOptions(TargetKind::Get(target_kind_name));
}

Hey what do you think of my proposal? It could completely avoid creating dummy targets in TVMC and preserve the warning message :-)

From a user perspective if you want to try it out very quickly and for the interest of being explicit,  these just show up from using tlcpack-nightly from https://tlcpack.ai ..

@u99127 Yep those warnings are annoying and that’s exactly we need to avoid. With my proposal (avoid creating dummy Target objects), these warnings won’t pop up

Would you guys mind if I take over and implement my proposed approach to avoid creating dummy objects that lead to messy warnings?

Would you guys mind if I take over and implement my proposed approach to avoid creating dummy objects that lead to messy warnings?

Hi @junrushao1994, sorry I didn’t reply, as I got some other things to finish this week. In case you have some time and want to follow the approach you suggested, I’m fine with it, otherwise I’ll look into it when I get some time. Thanks for the help and for offering to sort this out!!

@leandron Thanks! Submitted a follow-up PR #9662

Closing in favour of #9662


Kerchunk doesn't translate HDF5 hard links

I'm using kerchunk to translate hdf5 files in the H5MD format  to be readable by zarr.
Kerchunk doesn't translate hard links- wherever in the directory the h5py dataset was last assigned is the only place it remains in the resulting zarr directory and all other hard links are not visible.
Here's an example: First, I create an hdf5 file on the local filesystem
import h5py
import numpy as np

file_name = "example.h5"
with h5py.File(file_name, "w") as f:
    data = np.arange(10)
    dset = f.create_dataset("original_dataset", data=data)

    f["linked_dataset"] = f["/original_dataset"]

with h5py.File(file_name, "r") as f:
    print(f["original_dataset"])
    print(f["linked_dataset"])

This gives the output:
<HDF5 dataset "original_dataset": shape (10,), type "<i8">
<HDF5 dataset "linked_dataset": shape (10,), type "<i8">

However, when I do:
import kerchunk.hdf
import fsspec
import zarr

with fsspec.open(file_name) as inf:
    h5chunks = kerchunk.hdf.SingleHdf5ToZarr(
        inf, file_name, inline_threshold=100
    )
    fo = h5chunks.translate()

fs = fsspec.filesystem(
    "reference",
    fo=fo,
    skip_instance_cache=True,
)

z = zarr.open_group(fs.get_mapper(""), mode="r")
print(z.tree())

The tree looks like this:
/
 └── linked_dataset (10,) int64

This may be intentional behavior since zarr does not support linking datasets like hdf5 does. Is it possible to recreate the links in the json metadata created by kerchunk.hdf.SingleHdf5ToZarr to give the expected behavior? Please let me know if I'm missing anything!
For reference, I am using Kerchunk 0.2.5 and Python 3.11.9

You are quite right, this is not handled essentially because there is no obvious way to represent such links in zarr. With zarr V3, there has been talk about implementing links, but I'm not sure where that conversation is up to.
For kerchunk, we can recognise links, and for some special cases (single strings, IIRC) are handled. The question is what to do with the general case: should the metadata and references simply be duplicated?

Got it, sounds like this is already a known limitation. Would some kind of warning or note in the docs be appropriate? I'd be happy to open a quick PR.
This is a quick and dirty patch I'm using in my project to support hard links in H5MD, simply duplicates metadata:
Change in kerchunk.hdf.SingleHdf5ToZarr._translator

    def _translator(
        self,
        name: str,
        h5obj: Union[
            h5py.Dataset, h5py.Group, h5py.SoftLink, h5py.HardLink, h5py.ExternalLink
        ],
    ):
        """Produce Zarr metadata for all groups and datasets in the HDF5 file."""
        try:  # method must not raise exception
            kwargs = {}

            if isinstance(h5obj, h5py.SoftLink) or isinstance(h5obj, h5py.HardLink):
                h5obj = self._h5f[name]

Change in kerchunk.hdf.SingleHdf5ToZarr.translate
    def translate(self, preserve_links=False):
        """Translate content of one HDF5 file into Zarr storage format.

        This method is the main entry point to execute the workflow, and
        returns a "reference" structure to be used with zarr/kerchunk

        No data is copied out of the HDF5 file.

        Returns
        -------
        dict
            Dictionary containing reference structure.
        """
        lggr.debug("Translation begins")
        self._transfer_attrs(self._h5f, self._zroot)

        self._preserve_links = preserve_links
        if self._preserve_links:
            self._h5f.visititems_links(self._translator)
        else:
            self._h5f.visititems(self._translator)

This does require h5py>=3.11.0 since this is when h5py.Group.visititems_links was introduced

If it's optional, I think this would be a useful addition.


Please attach a small video that shows the functioning.

please asign this issue to me under GSSoC 24


Catch is preventing sleep

Catching is preventing sleep. Is it possible to fix this?

Duplicate of #24

yup, saw that a few moments ago. Sorry

No problem, triaging issues is part of the job :)


In 1.9 releases, attack damage should be affected by vanilla cooldowns.

Spam attacks currently will do the same amount of damage with custom items as it would with a charged attack in Minecraft version 1.9. I suggest adding an option in the config to enable custom weapons to coincide with the vanilla weapons in terms of how the combat works. An attack speed option for items would help as well although not needed.

You can set an item's damage mode to VANILLA (item's damage in vanilla minecraft) in 1.11 version and use nbt to control the damage. We will support MULTIPLY mode (item's damage in vanilla minecraft multiply with RPGItem damage). Use rpgitem [item] damagemode to switch between them.


Wrong property name in JavaCommonPresetOptions

Describe the bug
JavaCommonPresetOptions interface in src/generators/java/presets/CommonPreset.ts defines:
export interface JavaCommonPresetOptions {
  equal: boolean;
  hash: boolean;
  classToString: boolean;
}

see hash
but the actual code expects: options.hashCode
const shouldContainHashCode = options.hashCode === undefined || options.hashCode === true;

https://github.com/asyncapi/modelina/blame/master/src/generators/java/presets/CommonPreset.ts#L7
https://github.com/asyncapi/modelina/blame/master/src/generators/java/presets/CommonPreset.ts#L111
How to Reproduce
I found this when trying to generalize creation of JavaGenerator by creating a factory method for it. When I tried to use the example with this interface it obviously failed as (working) example states:
    {
      preset: JAVA_COMMON_PRESET,
      options: {
        hashCode: true,
        classToString: true,
      }
    }

Expected behavior
The options interface should match the actual options of the preset or it shouldn't be exported at all. From simple github search the interface is not used anywhere.
Extra note: maybe it would be nicer to also change equal -> equals as the generated method is equals not equal but that would be breaking change.

If the fix will be just changing the name of the property I could provide the simple PR.
/my first issue for this project so I didn't start with a PR and from what I see it probably won't be last but im happy to help :)/

Hey @kamko thanks for raising the issue!
That is indeed a bug, if you want to provide a PR fixing the issue that would be great, thanks!

Extra note: maybe it would be nicer to also change equal -> equals as the generated method is equals not equal but that would be breaking change.

That sounds like a good idea! Feel free to create a second issue highlighting the change you wish to see and why, as you did here. We are heading towards a breaking change regardless (and we are < 1) so don't worry about that 🙂


Update difforacle_amp() description

It was unclear that the qubits were not initialized to the uniform superposition

Thanks for your contribution!  Unfortunately, we don't use GitHub pull requests to manage code contributions to this repository as this is just a mirror. If you've spotted a typo, or have a content correction or suggestion for a new feature, please open a new Issue.


How to validate the telegram user id is valid or not in python??

Tell me how validate telegram user id is valid or not using python

Please follow issue template
If you want to chat, feel free to join our group.


Don't start datadog agent in run dynos.

This removes the broken DISABLE_DATADOG_AGENT env var and simply does not run the agent in one-off dynos.

@dreid what happened here? Did this not work out?

We're testing an alternative of just suppressing the initial log lines instead of not starting the agent.


Demo not working

Hey there, the video used in your demo at http://ma3str0.github.io/jquery-videosync/ can not be found:
http://e5t.ro/jquery_videosync_demo.mp4

Thanks, fixed


#0: linker script firware/kernel boundary alignment

Ticket
NA
Problem description
While looking at XIP support I noticed this fragment of linker script. There are three problems

The #if fragment setting __padding & __align is unconditionally overwritten, because the non ierisc path is not in a #else block. This kind of makes the following 2 points moot, but I mention them because maybe this is a latent bug?

the description of what is happening here is confusing and the behavior does not match 'needs 32bytes of padding'.  If the end address is 32m + n, one will get 31 bytes of padding when n == 1.  (one gets 32 bytes when n == 0 and 64-n for all other values. What I think it's trying to achieve is that the firmware and kernel do not share a (32byte?) cache line, and for that a simple ALIGN(32) is sufficient.  Perhaps additional padding is needed because of inst buffer read ahead straying past the firmware into the next cache line? But in any case we cannot flush the cache seems just broken -- what's to stop a first kernel sitting in the cache after memory is overwritten by a second kernel?

setting global symbols __align and __padding is undesirable -- this is being processed by the C preprocessor, we can just use #define

What's changed
Remove the ineffective code paths.
Checklist

[Yes ] Post commit CI passes
[ ] Blackhole Post commit (if applicable)
[ NA] Model regression CI testing passes (if applicable)
[ NA] Device performance regression CI testing passes (if applicable)
[ Yes] New/Existing tests provide coverage for changes

ah well


Consider to reintegrate eyeglass support

Not possible because importing syntax of third party modules requires node-sass-magic importer


The error was 'list' object has no attribute 'contents'

[Hey there! It seems an error has occured while running the importer.

The error was 'list' object has no attribute 'contents'.]

[Windows 10]
[importing notes from class with bullets converting them to html through LibreOffice]

Thank you for making this plug-in. I've been using it for a while for my classes but I encountered this in some .docx files. My classmates make notes in our class and it is in bullet form, that when I convert it to HTML, Anki could not detect any bullets thereby no cards were created.

Found a solution, click the bullet in MS Word then right click List Bullet 1 in Styles --> Update List Bullet 1 to Match Selection --> Change all the font because it will change the fonts in symbols. I don't know why this one works, just a noob on Python to explain why this one works.
Hope this helps.

I too encountered this issue. PFA associated file link (file will be deleted after 1 download)
https://file.io/sOOKl9MBXQby

How do I fix this issue? Thanks!


Adds the rustup target add command to docs

The compiler gives an error when following the documentation. This adds the missing piece.

Thanks!


Adding in a few updates to passwords for SSH

Adding updated years for Summer and Winter

thank you for you additions


Extend installation/usage instuctions

I think people will mostly try to hack on it, so Crystal Playground would be the best place to start. WDYT ?

I think so too. Thank you.


Put the most performant or restricting conditions/predicates at the start of an And[...] expression?

In this line:
https://github.com/RuleBasedIntegration/Rubi/blob/6ea8d532dddd6f13cfd8763ba1319df36f2ddf73/Rubi/IntegrationRules/1 Algebraic functions/1.1 Binomial products/1.1.1 Linear/<IP_ADDRESS> P(x) (a%2Bb x)^m (c%2Bd x)^n (e%2Bf x)^p (g%2Bh x)^q.m#L8
can we have the expression LtQ[p*q, 0] as first expression of the And[...] expression?
    LtQ[p*q, 0] && FreeQ[q, x] && PolyQ[Px, x] && PolyQ[Qx, x] && EqQ[PolynomialRemainder[Px, Qx, x], 0] && IntegerQ[p]

In general can we have the most performant or restricting conditions/predicates at the start of an And[...] expression after the /; operator?

Yes, the order an integration rule's application conditions are performed is not entirely fixed.  However, determing which condition provides the most bang-for-the-buck is extremely hard to determine in general.
For example, the FreeQ, PolyQ, and IntegerQ conditions in your example are quick and easy to perform.  They eliminate vast swaths of integrands, making application of the remaining conditions unnecessary.  Also, the condition LtQ[p*q, 0] can be hard to determine for arbitrary p and q.  Knowing that p is an integer and q is free of x greatly simplifies that determination.
I seriously doubt trying to determine the optimal ordering of the application conditions of Rubi's 6500+ rules would be worth the effort.


List of nodes

Previosly i asked you on https://medium.com/octavian-ai/finding-shortest-paths-with-graph-networks-807c5bbfc9c8 , but you didn't answer. Is this neural network can return the path ? I mean the list of nodes, not just a count of nodes. Maybe i didn’t understand something.

This specific example cannot return you the list of nodes because the answer the network was trained on was the count of nodes. However I believe it is possible to return the actual path of the shortest path by replacing all of the answers with the result from running every graph in the dataset with Dijkstra's algorithm.


Installation faild Nazara on Mac M2

Before this was working !!

As I said on Discord, that's because of an older nzsl package, reinstall it:
xrepo remove --all --yes nzsl
xmake config --check

Closed for inactivity.


Add a robust method for detecting the number of speakers

The diarization works better when the number of speakers is explicitly stated. However automatic speaker number detection is quite poor at the moment.

Might be solved with a better diarization backend https://github.com/Wordcab/wordcab-transcribe/issues/12

Closed by #31


version 1.4.0 broke our service discovery

What did you do?
we've accidentally upgraded our prometheus setup to 1.4.0 (from 1.3.1)
What did you expect to see?
the list of targets from all our dc, which we're getting via consul
What did you see instead? Under which circumstances?
the list of targets we got from consul was partial. we only saw a subset of the targets. and different subset everytime we restarted prometheus
Environment
prom/prometheus image over docker

System information:
insert output of uname -srm here
Linux 3.13.0-100-generic x86_64

Prometheus version:
we were using the master image (prom/prometheus). problem disappered with prom/prometheus:v.1.3.1
insert output of prometheus -version here

Alertmanager version:
insert output of alertmanager -version here (if relevant to the issue)

Prometheus configuration file:
(I've sanitized the dc names here to xxx(number))

global:
  scrape_interval: 15s
  evaluation_interval: 15s

  external_labels:
    monitor: 'prometheus-server'

rule_files:

  - alerts/service_down.rules
  - alerts/bandwidth_status.rules
  - alerts/media_connectivity.rules
  - alerts/mlb_status.rules
  - alerts/conferences_status.rules
  - alerts/app_deploy.rules
  - alerts/node_status.rules
  - alerts/media_server_status.rules
  - alerts/streaming_connectivity_ratio.rules

scrape_configs:
  - job_name: 'consul'
    consul_sd_configs:
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx1'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx2'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx3'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx4'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx5'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx6'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx7'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx8'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx9'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx10'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx11'
       - server:   '<IP_ADDRESS>:8500'
         datacenter: 'xxx12'

    relabel_configs:

      - source_labels: ['__meta_consul_tags']
        regex: '(.*),ignore-at-prometheus,(.*)'
        action: drop

      - source_labels: ['__meta_consul_tags']
        regex: '(.*),decommissioned,(.*)'
        action: drop

      - source_labels: ['__address__']
        separator:     ':'
        regex:         '(.*):(8300)'
        action:        drop

      - source_labels: ['__meta_consul_service']
        regex:         '(.*)telegraf-(.*)'
        target_label: '__meta_consul_service'
        replacement:   '$1$2'

      - source_labels: ['__meta_consul_service']
        regex:         '(.*)'
        target_label: 'job'
        replacement:   '$1'

Alertmanager configuration file:

insert configuration here (if relevant to the issue)

Logs:

insert Prometheus and Alertmanager logs relevant to the issue here

Can you try head? A fix for consul SD was just submitted.

@brian-brazil, Could you provide a docker image I can use?

It's not released yet. You'll have to build one yourself.

tested with head. looks good.
Version	1.4.0
Revision	d95e61d418ec98cdb8b14fecca39c03e70fa56a5

Great, thanks!


Changing the Rate of a Sound

Is there any way of changing the speed and or pitch of a recorded sound? Something along the lines of:
sound.rate(1.5)
or
sound.speed(1.5)
or
sound.pitch(1.5)
I know you can change the speed and pitch of oscillators, but I would like to change the pitch of a recorded sound. Howler does this with sound.rate(1.5).

Wads do have a setSpeed method, but they didn't have speed available as an argument on the constructor, or on play. I just added speed as an argument, so now you should be able to play audio clips at different speeds.
var audioClip = new Wad({source:'./audio-clip.mp3'})
audioClip.play({speed: 0.5})
audioClip.play({speed: 2.0})

Thank you, it works perfectly!
I would personally hesitate at calling it "speed" because it is both speed and pitch, and instead call it rate, but it's not a big deal.


[Android] Enable onOverScrolled API in XWalkView.

This PR is companied by PR 330# in chromium-crosswalk.
BUG=XWALK-4871
BUG=XWALK-4894

@axinging @lincsoon PTAL.

Thx shaobo, LGTM.


fix: consider the case where m_start_time is 0 in BaseLogFile::roll

Problem
In the second and subsequent log rolling, the start date of the log file name is set to "19700101" when all of the following conditions are met.

proxy.config.log.rolling_allow_empty is set to 1
there is no writing to the log file

How to reproduce

Set the following configuration to records.yaml

  log:
    rolling_enabled: 1
    rolling_interval_sec: 60
    rolling_allow_empty: 1

Set the following configuration to logging.yaml

---
logging:
  formats:
  - name: sample
    format: "%<cqtd> %<cqtt> %<cquuc> %<crc>"
  logs:
  - mode: ascii
    filename: access
    format: sample

Launch Traffic Server
After waiting a few minutes, the following logs are created

access.log_{hostname}.20230413.09h19m45s-20230413.09h20m00s.old
access.log_{hostname}.19700101.09h00m00s-20230413.09h21m00s.old
access.log_{hostname}.19700101.09h00m00s-20230413.09h22m00s.old
access.log_{hostname}.19700101.09h00m00s-20230413.09h23m00s.old
access.log_{hostname}.19700101.09h00m00s-20230413.09h24m00s.old
access.log_{hostname}.19700101.09h00m00s-20230413.09h25m00s.old

Cause
After the log rolling, m_start_time is reset and never been updated if there is no writing to the log file.
https://github.com/apache/trafficserver/blob/fc0690bdb407871ca2ae5c309553fe9925bb586f/src/tscore/BaseLogFile.cc#L199
https://github.com/apache/trafficserver/blob/fc0690bdb407871ca2ae5c309553fe9925bb586f/proxy/logging/LogFile.cc#L441
So,  the start date of the log file name is set to "19700101" because it isn't checked whether m_start_time is 0 in BaseLogFile::roll.

[approve ci]

[approve ci centos]

Thank you for the fix @yknoya .


Your theme's demo is not working on the Hugo Themes website

Hello @vjeantet
This is related to what has already been reported at #166
Your theme's demo is not generating on the Hugo Site when I test the Example Site with hugo server I get the following errors:
Building sites … ERROR 2018/11/08 14:40:38 render of "section" failed: execute of template failed: template: _default/list.html:13:9: executing "_default/list.html" at <partial (printf "%s/...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/flex/body-beforecontent.html:2:10": execute of template failed: template: partials/flex/body-beforecontent.html:3:7: executing "partials/flex/body-beforecontent.html" at <partial "header.html...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/header.html:2:10": execute of template failed: template: partials/header.html:2:10: executing "partials/header.html" at <where .Site.Pages "S...>: error calling where: Source isn't a field of struct type *hugolib.Page
ERROR 2018/11/08 14:40:38 render of "section" failed: execute of template failed: template: _default/list.html:13:9: executing "_default/list.html" at <partial (printf "%s/...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/flex/body-beforecontent.html:2:10": execute of template failed: template: partials/flex/body-beforecontent.html:3:7: executing "partials/flex/body-beforecontent.html" at <partial "header.html...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/header.html:2:10": execute of template failed: template: partials/header.html:2:10: executing "partials/header.html" at <where .Site.Pages "S...>: error calling where: Source isn't a field of struct type *hugolib.Page
ERROR 2018/11/08 14:40:38 render of "section" failed: execute of template failed: template: _default/list.html:13:9: executing "_default/list.html" at <partial (printf "%s/...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/flex/body-beforecontent.html:2:10": execute of template failed: template: partials/flex/body-beforecontent.html:3:7: executing "partials/flex/body-beforecontent.html" at <partial "header.html...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/header.html:2:10": execute of template failed: template: partials/header.html:2:10: executing "partials/header.html" at <where .Site.Pages "S...>: error calling where: Source isn't a field of struct type *hugolib.Page
ERROR 2018/11/08 14:40:38 render of "page" failed: execute of template failed: template: _default/single.html:13:9: executing "_default/single.html" at <partial (printf "%s/...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/flex/body-beforecontent.html:2:10": execute of template failed: template: partials/flex/body-beforecontent.html:3:7: executing "partials/flex/body-beforecontent.html" at <partial "header.html...>: error calling partial: "hugoThemes/docdock/hugo-theme-docdock/layouts/partials/header.html:2:10": execute of template failed: template: partials/header.html:2:10: executing "partials/header.html" at <where .Site.Pages "S...>: error calling where: Source isn't a field of struct type *hugolib.Page
Total in 924 ms

When I run the Themes Site Build Script I get the following very long list warnings:
 ==== PROCESSING  docdock  ======
Building site for theme docdock using config "config-docdock.toml" to ../themeSite/static/theme/docdock/
WARN 2018/11/08 14:35:41 Found no layout for "page", language "en", output format "HTML": create a template below /layouts with one of these filenames: post/single.en.html.html, post/single.html.html, post/single.en.html, post/single.html, _default/single.en.html.html, _default/single.html.html, _default/single.en.html, _default/single.html
WARN 2018/11/08 14:35:41 Found no layout for "page", language "en", output format "HTML": create a template below /layouts with one of these filenames: post/single.en.html.html, post/single.html.html, post/single.en.html, post/single.html, _default/single.en.html.html, _default/single.html.html, _default/single.en.html, _default/single.html
WARN 2018/11/08 14:35:41 Found no layout for "page", language "en", output format "HTML": create a template below /layouts with one of these filenames: single.en.html.html, single.html.html, single.en.html, single.html, _default/single.en.html.html, _default/single.html.html, _default/single.en.html, _default/single.html
WARN 2018/11/08 14:35:41 Found no layout for "page", language "en", output format "HTML": create a template below /layouts with one of these filenames: post/single.en.html.html, post/single.html.html, post/single.en.html, post/single.html, _default/single.en.html.html, _default/single.html.html, _default/single.en.html, _default/single.html
WARN 2018/11/08 14:35:41 Found no layout for "page", language "en", output format "HTML": create a template below /layouts with one of these filenames: post/single.en.html.html, post/single.html.html, post/single.en.html, post/single.html, _default/single.en.html.html, _default/single.html.html, _default/single.en.html, _default/single.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomyTerm", language "en", output format "HTML": create a template below /layouts with one of these filenames: categories/category.terms.en.html.html, categories/terms.en.html.html, categories/list.en.html.html, categories/category.terms.html.html, categories/terms.html.html, categories/list.html.html, categories/category.terms.en.html, categories/terms.en.html, categories/list.en.html, categories/category.terms.html, categories/terms.html, categories/list.html, taxonomy/category.terms.en.html.html, taxonomy/terms.en.html.html, taxonomy/list.en.html.html, taxonomy/category.terms.html.html, taxonomy/terms.html.html, taxonomy/list.html.html, taxonomy/category.terms.en.html, taxonomy/terms.en.html, taxonomy/list.en.html, taxonomy/category.terms.html, taxonomy/terms.html, taxonomy/list.html, category/category.terms.en.html.html, category/terms.en.html.html, category/list.en.html.html, category/category.terms.html.html, category/terms.html.html, category/list.html.html, category/category.terms.en.html, category/terms.en.html, category/list.en.html, category/category.terms.html, category/terms.html, category/list.html, _default/category.terms.en.html.html, _default/terms.en.html.html, _default/list.en.html.html, _default/category.terms.html.html, _default/terms.html.html, _default/list.html.html, _default/category.terms.en.html, _default/terms.en.html, _default/list.en.html, _default/category.terms.html, _default/terms.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: categories/category.en.html.html, categories/taxonomy.en.html.html, categories/list.en.html.html, categories/category.html.html, categories/taxonomy.html.html, categories/list.html.html, categories/category.en.html, categories/taxonomy.en.html, categories/list.en.html, categories/category.html, categories/taxonomy.html, categories/list.html, taxonomy/category.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/category.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/category.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/category.html, taxonomy/taxonomy.html, taxonomy/list.html, category/category.en.html.html, category/taxonomy.en.html.html, category/list.en.html.html, category/category.html.html, category/taxonomy.html.html, category/list.html.html, category/category.en.html, category/taxonomy.en.html, category/list.en.html, category/category.html, category/taxonomy.html, category/list.html, _default/category.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/category.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/category.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/category.html, _default/taxonomy.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: tags/tag.en.html.html, tags/taxonomy.en.html.html, tags/list.en.html.html, tags/tag.html.html, tags/taxonomy.html.html, tags/list.html.html, tags/tag.en.html, tags/taxonomy.en.html, tags/list.en.html, tags/tag.html, tags/taxonomy.html, tags/list.html, taxonomy/tag.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/tag.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/tag.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/tag.html, taxonomy/taxonomy.html, taxonomy/list.html, tag/tag.en.html.html, tag/taxonomy.en.html.html, tag/list.en.html.html, tag/tag.html.html, tag/taxonomy.html.html, tag/list.html.html, tag/tag.en.html, tag/taxonomy.en.html, tag/list.en.html, tag/tag.html, tag/taxonomy.html, tag/list.html, _default/tag.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/tag.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/tag.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/tag.html, _default/taxonomy.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: tags/tag.en.html.html, tags/taxonomy.en.html.html, tags/list.en.html.html, tags/tag.html.html, tags/taxonomy.html.html, tags/list.html.html, tags/tag.en.html, tags/taxonomy.en.html, tags/list.en.html, tags/tag.html, tags/taxonomy.html, tags/list.html, taxonomy/tag.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/tag.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/tag.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/tag.html, taxonomy/taxonomy.html, taxonomy/list.html, tag/tag.en.html.html, tag/taxonomy.en.html.html, tag/list.en.html.html, tag/tag.html.html, tag/taxonomy.html.html, tag/list.html.html, tag/tag.en.html, tag/taxonomy.en.html, tag/list.en.html, tag/tag.html, tag/taxonomy.html, tag/list.html, _default/tag.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/tag.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/tag.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/tag.html, _default/taxonomy.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: categories/category.en.html.html, categories/taxonomy.en.html.html, categories/list.en.html.html, categories/category.html.html, categories/taxonomy.html.html, categories/list.html.html, categories/category.en.html, categories/taxonomy.en.html, categories/list.en.html, categories/category.html, categories/taxonomy.html, categories/list.html, taxonomy/category.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/category.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/category.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/category.html, taxonomy/taxonomy.html, taxonomy/list.html, category/category.en.html.html, category/taxonomy.en.html.html, category/list.en.html.html, category/category.html.html, category/taxonomy.html.html, category/list.html.html, category/category.en.html, category/taxonomy.en.html, category/list.en.html, category/category.html, category/taxonomy.html, category/list.html, _default/category.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/category.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/category.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/category.html, _default/taxonomy.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: tags/tag.en.html.html, tags/taxonomy.en.html.html, tags/list.en.html.html, tags/tag.html.html, tags/taxonomy.html.html, tags/list.html.html, tags/tag.en.html, tags/taxonomy.en.html, tags/list.en.html, tags/tag.html, tags/taxonomy.html, tags/list.html, taxonomy/tag.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/tag.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/tag.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/tag.html, taxonomy/taxonomy.html, taxonomy/list.html, tag/tag.en.html.html, tag/taxonomy.en.html.html, tag/list.en.html.html, tag/tag.html.html, tag/taxonomy.html.html, tag/list.html.html, tag/tag.en.html, tag/taxonomy.en.html, tag/list.en.html, tag/tag.html, tag/taxonomy.html, tag/list.html, _default/tag.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/tag.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/tag.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/tag.html, _default/taxonomy.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: tags/tag.en.html.html, tags/taxonomy.en.html.html, tags/list.en.html.html, tags/tag.html.html, tags/taxonomy.html.html, tags/list.html.html, tags/tag.en.html, tags/taxonomy.en.html, tags/list.en.html, tags/tag.html, tags/taxonomy.html, tags/list.html, taxonomy/tag.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/tag.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/tag.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/tag.html, taxonomy/taxonomy.html, taxonomy/list.html, tag/tag.en.html.html, tag/taxonomy.en.html.html, tag/list.en.html.html, tag/tag.html.html, tag/taxonomy.html.html, tag/list.html.html, tag/tag.en.html, tag/taxonomy.en.html, tag/list.en.html, tag/tag.html, tag/taxonomy.html, tag/list.html, _default/tag.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/tag.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/tag.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/tag.html, _default/taxonomy.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "home", language "en", output format "HTML": create a template below /layouts with one of these filenames: index.en.html.html, home.en.html.html, list.en.html.html, index.html.html, home.html.html, list.html.html, index.en.html, home.en.html, list.en.html, index.html, home.html, list.html, _default/index.en.html.html, _default/home.en.html.html, _default/list.en.html.html, _default/index.html.html, _default/home.html.html, _default/list.html.html, _default/index.en.html, _default/home.en.html, _default/list.en.html, _default/index.html, _default/home.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "section", language "en", output format "HTML": create a template below /layouts with one of these filenames: post/post.en.html.html, post/section.en.html.html, post/list.en.html.html, post/post.html.html, post/section.html.html, post/list.html.html, post/post.en.html, post/section.en.html, post/list.en.html, post/post.html, post/section.html, post/list.html, section/post.en.html.html, section/section.en.html.html, section/list.en.html.html, section/post.html.html, section/section.html.html, section/list.html.html, section/post.en.html, section/section.en.html, section/list.en.html, section/post.html, section/section.html, section/list.html, _default/post.en.html.html, _default/section.en.html.html, _default/list.en.html.html, _default/post.html.html, _default/section.html.html, _default/list.html.html, _default/post.en.html, _default/section.en.html, _default/list.en.html, _default/post.html, _default/section.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomyTerm", language "en", output format "HTML": create a template below /layouts with one of these filenames: tags/tag.terms.en.html.html, tags/terms.en.html.html, tags/list.en.html.html, tags/tag.terms.html.html, tags/terms.html.html, tags/list.html.html, tags/tag.terms.en.html, tags/terms.en.html, tags/list.en.html, tags/tag.terms.html, tags/terms.html, tags/list.html, taxonomy/tag.terms.en.html.html, taxonomy/terms.en.html.html, taxonomy/list.en.html.html, taxonomy/tag.terms.html.html, taxonomy/terms.html.html, taxonomy/list.html.html, taxonomy/tag.terms.en.html, taxonomy/terms.en.html, taxonomy/list.en.html, taxonomy/tag.terms.html, taxonomy/terms.html, taxonomy/list.html, tag/tag.terms.en.html.html, tag/terms.en.html.html, tag/list.en.html.html, tag/tag.terms.html.html, tag/terms.html.html, tag/list.html.html, tag/tag.terms.en.html, tag/terms.en.html, tag/list.en.html, tag/tag.terms.html, tag/terms.html, tag/list.html, _default/tag.terms.en.html.html, _default/terms.en.html.html, _default/list.en.html.html, _default/tag.terms.html.html, _default/terms.html.html, _default/list.html.html, _default/tag.terms.en.html, _default/terms.en.html, _default/list.en.html, _default/tag.terms.html, _default/terms.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: tags/tag.en.html.html, tags/taxonomy.en.html.html, tags/list.en.html.html, tags/tag.html.html, tags/taxonomy.html.html, tags/list.html.html, tags/tag.en.html, tags/taxonomy.en.html, tags/list.en.html, tags/tag.html, tags/taxonomy.html, tags/list.html, taxonomy/tag.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/tag.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/tag.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/tag.html, taxonomy/taxonomy.html, taxonomy/list.html, tag/tag.en.html.html, tag/taxonomy.en.html.html, tag/list.en.html.html, tag/tag.html.html, tag/taxonomy.html.html, tag/list.html.html, tag/tag.en.html, tag/taxonomy.en.html, tag/list.en.html, tag/tag.html, tag/taxonomy.html, tag/list.html, _default/tag.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/tag.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/tag.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/tag.html, _default/taxonomy.html, _default/list.html
WARN 2018/11/08 14:35:41 Found no layout for "taxonomy", language "en", output format "HTML": create a template below /layouts with one of these filenames: tags/tag.en.html.html, tags/taxonomy.en.html.html, tags/list.en.html.html, tags/tag.html.html, tags/taxonomy.html.html, tags/list.html.html, tags/tag.en.html, tags/taxonomy.en.html, tags/list.en.html, tags/tag.html, tags/taxonomy.html, tags/list.html, taxonomy/tag.en.html.html, taxonomy/taxonomy.en.html.html, taxonomy/list.en.html.html, taxonomy/tag.html.html, taxonomy/taxonomy.html.html, taxonomy/list.html.html, taxonomy/tag.en.html, taxonomy/taxonomy.en.html, taxonomy/list.en.html, taxonomy/tag.html, taxonomy/taxonomy.html, taxonomy/list.html, tag/tag.en.html.html, tag/taxonomy.en.html.html, tag/list.en.html.html, tag/tag.html.html, tag/taxonomy.html.html, tag/list.html.html, tag/tag.en.html, tag/taxonomy.en.html, tag/list.en.html, tag/tag.html, tag/taxonomy.html, tag/list.html, _default/tag.en.html.html, _default/taxonomy.en.html.html, _default/list.en.html.html, _default/tag.html.html, _default/taxonomy.html.html, _default/list.html.html, _default/tag.en.html, _default/taxonomy.en.html, _default/list.en.html, _default/tag.html, _default/taxonomy.html, _default/list.html

Can you please look into the above, so that your theme's demo is generated again. Also if you would like to test your theme locally with the Hugo Themes Build Script there are detailed instructions here
CC / @digitalcraftsman

Hi @onedrawingperday,
Could you check if this is solved now?

Thank you for the swift reply @Pilskalns
I confirm that now your theme's demo is generated when I execute the Build Script.
This will be reflected on the Hugo website the next time themes are updated.
Thanks.