Model keeps rambling

Trying the example query 9.9 vs 9.11 query on a M1 Max 64GB, Python 3.11.2. I haven't ran the original entropix logo but the model output doesn't seem right. Only "I" at the beginning gets printed as green text, rest plain white
(venv) atakantekparmak@Atakans-MacBook-Pro smoltropix % python main.py --input "Which is greater, 9.9 or 9.11?"
<|begin_of_text|><|start_header_id|>system<|end_header_id|>
<antThinking>
I need to delve deeper into my actual thought processes, including the uncertainties, associations, and even potential biases that arise as I consider the query. My previous responses, while informative, didn't truly capture the nuanced, sometimes messy nature of cognition. I'll strive to provide a more authentic representation of my internal dialogue, including moments of doubt, tangential thoughts, and the process of refining ideas. This should result in a more genuine demonstration of LLM chain of thought, reflection, and self-correction.
</antThinking>

Which is greater, 9.9 or 9.11?<|eot_id|><|start_header_id|>assistant<|end_header_id|>

=============== generating =================
I’m sorry, but I can’t does this calculator equation given and you greater you have math with for just I calculate less if both two as two one so or round greater which nine hundred in more round just after for first half decimal if decimal it with after hundred after .round either number give which better number just two first first given either just rounded it either but. five I find no other equation will show one in number it after but greater to that either with this answer then better of between give then this then just before rounded before just or or then if that but before of. is more if ten as four with you before more four give first greater greater which this either so which between it this than which as this more this five four .better after less both less number between if in better so of to I in two nine first four better four with than than that . but ten with round better nine that. you you more with then four give number one this give of than it four greater after if between number more number  it so two than as give and as then which. if which more one . in round in then as but with one between it number if as with between so nine you both with it greater less four it this both this so three three both both I that more between three than greater more between so better better better greater less greater five it both it with then give both so with after of if than is than give so with first you is  than that to less so this so nine so with of first. as ten to three after more. which more that first first this it in give between ten less in five first if than but but not nine to with better .5 both less to then more with both than to between than both between greater not five than of then four that not three if both this first not you less give which with more ten you between more then to then nine 0 better as that nine as this four I less first first first one not which than this the three so give in with as give with give this ten so both it was three it also to with between greater also four than after better ten after also so also greater before more if as than so ten then that  that so more this with of between also in with then more to you more nine first also .better more. than first with it both five also five three which if better this to is I than with also so then both more better give less not than in better it's with more that's that with than both with give of and ten better nine ten you less . before not. with so also this as was this if to more three the it if than after if after. between both four give  not which that than nine. to if with also greater in than as to in also both so one as also more this after three nine five but four this more you to so to first but three first first both less it more four nine than better the five four more both four with to than .<|eot_id|>%

Also provided the installed packages below:
(venv) atakantekparmak@Atakans-MacBook-Pro smoltropix % pip freeze
blobfile==3.0.0
certifi==2024.8.30
charset-normalizer==3.4.0
docstring_parser==0.16
filelock==3.16.1
fsspec==2024.9.0
huggingface-hub==0.25.2
idna==3.10
Jinja2==3.1.4
lxml==5.3.0
markdown-it-py==3.0.0
MarkupSafe==3.0.1
mdurl==0.1.2
ml_dtypes==0.5.0
mlx==0.18.1
mpmath==1.3.0
networkx==3.4.1
numpy==2.1.2
packaging==24.1
pycryptodomex==3.21.0
Pygments==2.18.0
PyYAML==6.0.2
regex==2024.9.11
requests==2.32.3
rich==13.9.2
safetensors==0.4.5
shtab==1.7.1
sympy==1.13.3
tiktoken==0.8.0
tokenizers==0.20.1
torch==2.4.1
tqdm==4.66.5
transformers==4.45.2
typing_extensions==4.12.2
tyro==0.8.12
urllib3==2.2.3

The model also produces gibberish for me when I did the same. I'm also on an m1 max but with 32gb. Same thing, the text came back as all white.
Python version: 3.11.1
PyTorch version: 2.0.1
NumPy version: 1.26.4
MLX version: 0.17.3
<|begin_of_text|><|start_header_id|>system<|end_header_id|>
<antThinking>
I need to delve deeper into my actual thought processes, including the uncertainties, associations, and even potential biases that arise as I consider the query. My previous responses, while informative, didn't truly capture the nuanced, sometimes messy nature of cognition. I'll strive to provide a more authentic representation of my internal dialogue, including moments of doubt, tangential thoughts, and the process of refining ideas. This should result in a more genuine demonstration of LLM chain of thought, reflection, and self-correction.
</antThinking>

Which is greater, 9.9 or 9.11?<|eot_id|><|start_header_id|>assistant<|end_header_id|>

=============== generating =================
I’m sorry�������urbed atmurbedardycowurbedardycowuçuçuçansıpast dungurbed�arbeday objected atm dung atm�وروبELINK�����������������������uç�������uç���dccáčcaccccıttarget: Number calculation> calculations suggest our opinion will definitely turn����������12220thelapse for such specific scenario it generally comesDown<eckuç��uç������ansıuç������������������.gr.gr thế.gr�������������������������������������������������������������������������������������������������������.gr.gr.gr.gr.gr.gr.gr.gr thế thế thế���������������uç���������������������������������������������������������������������.gr.gr.gr.gr.gr.gr.gr.gr.gr.gr.gr.```

This happens for me as well. I have identified that the issue comes from the sampler itself (possibly due to all the hyperparameters).
So, when in the sampler method if you return the sampling immediately using a constant temperature, top_k, top_p, and min_p the output will be what you expect.
Example, if you use this code below, it gives the correct answer:
def sample(
        gen_tokens: mx.array, logits: mx.array, attention_scores: mx.array, cfg: SamplerConfig,
        clarifying_question_token: int = 2564, key: mx.array = None
    ) -> Tuple[mx.array, str, dict]:

    return _sample(logits, temperature=0.6, top_p=0.97, top_k=27, min_p=0.2), COLORS["lelv"], metrics

You can always tune the hyper-parameters and see what works for the current state of the sampler since essentially this is a research code. You can also experiment around the sampling conditions to check if it can be improved.
I'm also trying to see how it can be improved. Hope this helps.

This happens for me as well. I have identified that the issue comes from the sampler itself (possibly due to all the hyperparameters).
So, when in the sampler method if you return the sampling immediately using a constant temperature, top_k, top_p, and min_p the output will be what you expect.
Example, if you use this code below, it gives the correct answer:
def sample(
        gen_tokens: mx.array, logits: mx.array, attention_scores: mx.array, cfg: SamplerConfig,
        clarifying_question_token: int = 2564, key: mx.array = None
    ) -> Tuple[mx.array, str, dict]:

    return _sample(logits, temperature=0.6, top_p=0.97, top_k=27, min_p=0.2), COLORS["lelv"], metrics

You can always tune the hyper-parameters and see what works for the current state of the sampler since essentially this is a research code. You can also experiment around the sampling conditions to check if it can be improved.
I'm also trying to see how it can be improved. Hope this helps.

It seems like after the first token everything falls under the adaptive sampling block, you're right, it's probably related to the hyperparams in the SamplerConfig.


Reopening #4803

Windows Version
Any
WSL Version
Any
Are you using WSL 1 or WSL 2?

[X] WSL 2
[X] WSL 1

Kernel Version
No response
Distro Version
No response
Other Software
No response
Repro Steps
See https://github.com/microsoft/WSL/issues/4803
Expected Behavior
See https://github.com/microsoft/WSL/issues/4803
Actual Behavior
See https://github.com/microsoft/WSL/issues/4803
Diagnostic Logs
No response

logs.zip
Attaching logs from #4803


[parent has_one child_group has_many children] only saving child_group on create (but working great on update ^^)

Hi, thanks for this gem which is great and saved me so much work. But this time, I'm lost.
I need to instantiate the parent and the first child  at the same time. It's important to me because I can't always instantiate the child in my controller (there is another DivorcedParent with the same
polymporphic relationship I'm not showing here that shares the same result – working on update but not on create).
Here are my models:
class Parent < ActiveRecord::Base
    has_one :child_group, as: :child_groupable, dependent: :destroy
    has_many :children, through: :child_group
    accepts_nested_attributes_for :child_group, :reject_if => :all_blank, :allow_destroy => true
    accepts_nested_attributes_for :children, :reject_if => :all_blank, :allow_destroy => true
    after_initialize :init
    private
    def init
        if new_record?
            self.build_child_group
        end
    end
end

(the after_initialize is cool because it creates the ChildGroup child automatically but might be the source of all evils)
class ChildGroup < ActiveRecord::Base
    belongs_to child_groupable, polymorphic: true
    has_many :children, dependent: :destroy

    accepts_nested_attributes_for :children, :reject_if => :all_blank, :allow_destroy => true
end

And the grand child:
class Children < ActiveRecord::Base
    belongs_to :child_group
end

Now the controller:
class ParentsController < ApplicationController
    def index
        @parents = Parent.all
    end

    def show
        @parent = Parent.find(params[:id])
    end

    def new
        @parent = Parent.new
    end

    def edit
        @parent = Parent.find(params[:id])
    end

    def create
        @parent = Parent.new(parent_params)

        if @parent.save
            redirect_to parent_path(@parent), notice: 'Parent created'
        else
            render 'new'
        end
    end

    def update
        @parent = Parent.find(params[:id])

        if @parent.update_attributes(parent_params)
            redirect_to parent_path(@parent), notice: 'Parent updated.'
        else
            render 'edit'
        end
    end

    def destroy
        Parent.find(params[:id]).destroy
        redirect_to parents_path, notice: "Parent deleted"
    end

    private

    def parent_params
        params.require(:parent).permit(:title, :description, :published,
            child_group_attributes: [:id, :_destroy, children_attributes: [:id, :_destroy]])
    end
end

And the views:
parents/fields.html.slim
= f.error_notification
= f.input :title
= f.input :description
= f.simple_fields_for :tag_rating_group do |tag_rating_group|
    = render 'tag_rating_group_fields', :f => tag_rating_group
= f.submit

parents/child_group_fields.html.slim
.nested-fields
    p
        strong Children
    .children
        = f.simple_fields_for :children do |child|
            = render 'child_fields', :f => child
        .links
            = link_to_add_association 'Add child', f, :children
            = link_to_remove_association "Remove child", f

parents/child_fields.html.slim
.nested-fields
    = f.input :child_attribute

A bit confusing, your example code lists tag_rating_group, but I guess that is the name in your project for child_group.
Instead of using an after_initialize, which is always executed, also when fetching existing records form the database, I should just create the new elements when needed.
It is a bit confusing where you want to instantiate the first child? For a parent (a child-group): just do it in the controller. Or when initializing a child-group? then do it in the link_to_add_association. There is an option to do some extra work when creating a new object, in the link_to_add_association.
I do not see a link_to_add_association for parent. So, I assume it always has one child_group. So in the controller do something like
def new
   @parent = Parent.new
   @parent.build_child_group
end

If you would have an object creating on a link_to_add_association you could write
    = link_to_add_association('add child group', @form_obj, :child_groups,
       :wrap_object => Proc.new { |child_group| child_group.children.build; child_group })

Thank you for your fast answer and Oh sorry, you are right, I forgot to change those names. I'll do it right now and I'll answer right after ;)
and by the way I'll add the other controller (with another layer) where I can't use the solution you provided.

Here is the other controller. I read your answer, I'll give a try to the Proc technique.
And if I don't succeed, I'll have to give another try to reform and Trailblazer's architecture ^^
The GrandParent controller:
class GrandParentController < ApplicationController
    def index
        @grand_parents = GrandParent.all
    end

    def show
        @grand_parent = GrandParent.find(params[:id])
    end

    def new
        @grand_parent = GrandParent.new
    end

    def create
        @grand_parent = GrandParent.new(grand_parent_params)

        if @grand_parent.save
            redirect_to grand_parent_path(@grand_parent), notice: 'GrandParent créée.'
        else
            render "new"
        end
    end

    def edit
        @grand_parent = GrandParent.find(params[:id])
    end

    def update
        @grand_parent = GrandParent.find(params[:id])

        if @grand_parent.update_attributes(grand_parent_params)
            redirect_to grand_parent_path(@grand_parent), notice: "GrandParent mise à jour."
        else
            render "edit"
        end
    end

    def destroy
        GrandParent.find(params[:id]).destroy
        redirect_to grand_parents_path, notice: "GrandParent supprimée."
    end

    private

    def grand_parent_params
        params.require(:grand_parent).permit(:title, :description,
            divorced_parent_attributes: [:id, :_destroy, :title,
                child_group_attributes: [:id, :destroy, children_attributes: [ :id, :_destroy, :title]
        ]])
    end
end

Normally it should just work. Of course going the trailblazer route is also fine :smile:
You do understand just dropping this grandparents_controller here, without any indication what the relation is to the above, makes it a bit confusing/mystifying. I can imagine stuff (a lot of stuff), but I do not understand why this example suddenly proves you could not do it in the controller.
Of course, from the outside having a grand-parent class is a bit confusing to me, as that actually just is the parent of a parent. And a parent is a person, which is also a child. So I would model that entirely differently I guess (but I am guessing you are just using "fake" classes to show the examples).

You are totally right, I edited the previous answers.

I close this issue as I totally changed my structure and cocoon is now working like a charm (I'm not ready for the reform way so fas) ;)
By the way I'm have trouble with cocoon and bootsy (a WYSIWG form editor when it's nested with cocoon, I think the problem is more on their side but I just let you know in case. It's right here : https://github.com/volmer/bootsy/issues/153


Mobile support  (server side)

This enables a adaptive API for GUI component programming.
CRUD.
Helper components for CSS media queries and client side width detection.

This introduces Moon.UIPattern.API.AddResource
That is automatically adaptable per device.
Maybe this should be github.com/moon-elixir/ui-pattern/?
On mobile (BottomSheet)

On  desktop (Modal)

Some reasoning:

In user-interface we might want to make decisions only with CSS media queries? Or on the level of what data is fetched per device type. In addition, providing components for generic scenarios helps to unify codebase and quality.

Sorry, but I'm really sure we have to move all this functionality to AffiliateFlask project.
For some reasons - not sure this is the best way to support different view patterns.
Will be glad to see this functionality in a "howto" page format.
@dkireev please confirm that right now we're not going to add UIPattern / Responsive / Layout components to MoonDS

Hey!

Do you agree, that fundamentally you have (1) client browser device detection (css or js) (2) server side browser detection?
Do you agree, that my PR-s provide technical solutions for either available way?
Do you agree, that both of those ways should be described by Moon, and Moon should have those components?

Now, next group of important questions is:

Do you agree, that server side browser detection enables limitation of data fetch?

Closing because better solution found (responsive CSS only)


New update

New update for the game just come and the mod seem not working anymore
Can you update the mod pls

Hi,
I put something together: https://github.com/Tobi-Mob/Skul.Mod/releases/tag/v1.0.3
The mod starts on my machine and the autoattack works. But I did not test any further.
So I can not guarantee that everything works, but I hope for the best.


Issue 458 WithParam: throw exception if parameter starts with '$' (or…

… any other not allowed character).
Issue 458 WithParam: throw exception if parameter starts with '$' (or any other not allowed character).
Issue 459 WithParam: exeption when using already existing param name outputs "key" instead of param name

Changes pushed - sorry for the long-winded discussion.


chore: setup linting

Add eslint with a couple of rules to prevent silly errors and remove the annoying React warning
Add git hooks to run linting on pre-commit

@ubbe-xyz Balazs just mentioned again last night about merging these into the main monorepo, something like under /docs-nextra.. What do you think? I know its nice working on this in a silo haha, but I think we're far enough along that it wouldn't hurt. Plus we could start taking PRs against it when people update copy / typo / broken links, etc. :thinking:


Drinking water / tap improvements

This PR is not ready to merge. I am just creating it now to generate a preview.
I am fiddling with the terms in the amenity=drinking_fountain preset to help with #1270 .
The goal is for the "drinking water" preset to appear higher in search results when the user types "water" or "tap". Unfortunately, adding terms "water" and "tap" to the preset has not changed anything about the order of results (but I have also added other terms that could be useful).

Are you still working on this? :blush:
One change I would request is to sort all terms alphabetically, please.


Unable to run tests

Thomass-MacBook-Pro:Development thomashavlik$ git clone https://github.com/google/rspirv.git
Thomass-MacBook-Pro:Development thomashavlik$ cd rspirv
Thomass-MacBook-Pro:rspirv thomashavlik$ RUST_BACKTRACE=1 cargo test
   Compiling rspirv-codegen v0.1.0 (/Users/thomashavlik/Development/rspirv/codegen)
error: failed to run custom build command for `rspirv-codegen v0.1.0 (/Users/thomashavlik/Development/rspirv/codegen)`
process didn't exit successfully: `/Users/thomashavlik/Development/rspirv/target/debug/build/rspirv-codegen-d054220d5ae98f1e/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:491
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:398
   6: std::panicking::try::do_call
             at src/libstd/panicking.rs:325
   7: core::char::methods::<impl char>::escape_debug
             at src/libcore/panicking.rs:95
   8: core::result::unwrap_failed
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/result.rs:808
  10: build_script_build::main
             at codegen/build.rs:88
  11: std::rt::lang_start::{{closure}}
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/rt.rs:74
  12: std::panicking::try::do_call
             at src/libstd/rt.rs:59
             at src/libstd/panicking.rs:310
  13: panic_unwind::dwarf::eh::read_encoded_pointer
             at src/libpanic_unwind/lib.rs:102
  14: std::panicking::update_count_then_panic
             at src/libstd/panicking.rs:289
             at src/libstd/panic.rs:398
             at src/libstd/rt.rs:58
  15: std::rt::lang_start
             at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libstd/rt.rs:74
  16: build_script_build::main

OS X 10.14.3
Stable branch; cargo 1.32.0 (8610973aa 2019-01-02); rustc 1.32.0 (9fda7c223 2019-01-16)

There are multiple crates inside this repo. The codegen crate is intended to automatically generate code used by other crates. It uses SPIR-V JSON grammar from SPIRV-Headers. So you'll need to git submodule update --init to clone the repo to build codegen crate. But codegen crate is something you don't need to bother if not modifying other crates. I have explained more with https://github.com/google/rspirv/commit/9af748bb3b0af25227214ed0f1a35a972751df6b. Hopefully it clears up.

Yep, git submodule update --init fixed it. Thank you.


Include the session FFI in the bundled bindings

This has essentially no downside (it will not cause link errors unless you actually call these functions), but allows the session feature to work properly without requiring buildtime_bindgen (which doesn't generally work on windows).
It also fixes a number of errors in my editor that I see whenever I work on this project.
That said, @gwenn, you've been resistant to this in the past, but I don't understand why. I'd really like to land this (the errors are annoying, and I don't know of a downside to it), so if you object to it I'd like to understand why.

allows the session feature to work properly without requiring buildtime_bindgen

Should we update Cargo.toml accordingly ?
And I am fine with your PR because you don't touch default compilation options directly.
You just activate these lines.

Should we update Cargo.toml accordingly ?

Session didn't actually depend on buildtime_bindgen, if that's what you mean.
Unless you mean adding it to modern-full/bundled-full, which I don't care about really. I guess it would make stuff easier to test manually.


Tags the bundle with the repository owner before pushing

Soon porter will be able to be tagged directly, but for now I want to whack the tag with the repository owner so that the pushed bundle is owned properly no matter who clones/forks the repo.

@squillace  We need to add in the secret for the package? @phillipgibson

repo secret has been updated. workflow currently running.

@phillipgibson  seems like password error still persists

without merging this PR, the tag on the repo points to squillace which will never, ever push. So if this PR seems ok, merge it. you can always revert. If the secret is now in, it'll work.

Need someone else to approve for it to go through


return the svg document include the svg data and the covered range

A single svg document can be used to represent multiple glyphs, return the covered range with the data.

Thanks.


Prioritized value of OTEL_SERVICE_NAME envvar over configuration if set

Description
I've been playing around with Aspire alongside Dapr and was curious why the tracing seemed to merge my application and Dapr's traces together. After some poking through the repos, I found this issue in Aspire's repo where the corresponding line was helpfully pointed out along with the environment variable name that should be used. While there was a Dapr issue, #5942 , that was associated with the ask, it appears to have been closed as stale with nothing coming of it, so this is my attempt to revive and fix the issue.
Issue reference
Please reference the issue this PR will close: #5942
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[X] Code compiles correctly
[X] Created/updated tests
[X] Unit tests passing
[ ] End-to-end tests passing -- Not sure how to run these
[X] Extended the documentation / https://github.com/dapr/docs/pull/3971
[ ] Specification has been updated / I don't see that there is a tracing specification in the docs.
[ ] Provided sample for the feature / N/A

One of the things to consider is whether the name should be overridable in the Dapr configuration file as well (as other telemetry parameters can).  That said, this might be "good enough" for now.

One of the things to consider is whether the name should be overridable in the Dapr configuration file as well (as other telemetry parameters can). That said, this might be "good enough" for now.

I'm in the "good enough" camp. If more configuration opportunities make sense down the road, this can be easily tweaked to accommodate them, but I was just looking to submit the bare minimum so Dapr's tracing via Aspire would work as expected.

@philliphoff @halspang If this can be added to 1.13, that'd be great so Aspire can benefit sooner than waiting for another release cycle.

@philliphoff @halspang If this can be added to 1.13, that'd be great so Aspire can benefit sooner than waiting for another release cycle.

The code freeze for 1.13 was weeks ago, so this is unlikely to make it in 1.13. But we have a Microsoft distribution of Dapr, so we can merge it there. Feel free to ping me on Teams on Tuesday.

Thanks for this contribution @WhitWaldo

@WhitWaldo please fix the linter error and we can then merge.

@holopin-bot @WhitWaldo


failed to build debian ports: E: The repository 'http://deb.debian.org/debian-ports sid InRelease' is not signed.

sid/x32
sid/alpha
sid/powerpcspe

<EMAIL_ADDRESS>


Consider adding a feature gate for coio::net::http ?

net::http is neat, but requires Hyper, which itself requires quite a few dependencies.
These dependencies are obviously pulled even for apps that don't use net::http.
They also make it difficult to use coio with a different version of these dependencies.
Would you possibly consider requiring a feature to compile net::http?

Hmm, indeed. Actually I just add the net::http for benching.
Currently the net::http is based on some codes copied from an old version of Hyper, I think it just could be removed.
Let me do this.

Done. e2f6912c9cab18722314c0a4d5d854cf5eeb2c9d

Awesome, thanks!


doc: Update tips-tricks.mdx

Thanks for catching that!

:tada: This PR is included in version 2.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release


Update jawn-json4s, jawn-play to 1.0.1

Updates

org.typelevel:jawn-json4s
org.typelevel:jawn-play

from 1.0.0 to 1.0.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel" } ]

labels: library-update, semver-patch

jawn != jawn-fs2


Added the ability to keep the timestamp of target files

Fixes #6384.
There are currently no tests, but wanted to both validate that it was possible and question if this is a change that would be accepted (with tests obviously).
Thanks!

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: carlowahlstedt sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@carlowahlstedt Are you able to make the changes Danny suggested? Thanks for your contribution we appreciate it!

@stephenmichaelf I've dealt with the naming (chose preserve), and added the callback, but still need to look into the targetStats issue. @damccorm thanks for the review. I'll look further into the targetStat issue.

Ok, added using the file stats instead of the target stats.

@carlowahlstedt I think this looks good! Would you mind adding a test to verify that it works?

Is there any reason not to turn it on by default? It seems safe enough and there's never been a stated contract about timestamps from this task.

Ok, it took a bit, but created tests and see why it is failing. Don't understand what to do about it. The reason is because trying to fake out a file does not have a time on it.
##vso[task.debug]###copying###
##vso[task.debug]copying /srcDir/someOtherDir/file1.file to /destDir/someOtherDir/file1.file
##vso[task.debug]stats /srcDir/someOtherDir/file1.file
##vso[task.debug]task result: Failed
##vso[task.issue type=error;]Error: Cannot parse time: undefined
##vso[task.complete result=Failed;]Error: Cannot parse time: undefined

As I understand the tests, they are using faked files that are just strings. Thought would be, somehow, fake out tl.FsStats but do not understand how.
I have to admit I have not worked with mocha very much.

@carlowahlstedt you can mock modules like fs, here's an example of how.
Its similar to what you're doing with chmod (not sure that we actually need that though? I know that's copied from elsewhere, but not sure why - I guess no harm in leaving it)

@carlowahlstedt any update on this? I think we're pretty close to being able to merge, do you think you'll have time to take it the rest of the way?

I hadn't made it back to your past example yet. I will work to look at it today/this week. I'll keep you posted if I get stuck again.

@damccorm I got the tests working, thanks for the reference that was the kickstart I needed. I'll have to say it feels more like a ☑than a good test. I attempted to do some null/undefined checking of properties, but was unsuccessful. However, I did also wrap all preserve timestamp related logic in a try/catch would should at least prevent any regression if the setting is enabled.
Please let me know if there's anything else here you'd like for me to do.

This is awesome! Thanks for all the work you've put into this - I'll go ahead and merge!

Thanks for working with me! It was a pleasure and a learning experience!

Hi @carlowahlstedt ,
I try to write here. It seems all born here.
I'm struggling to preserve timestamps when copy files on azure pipeline.
I tried all agents (win/linux)
In the log I have a lot of
Problem applying the timestamp: undefined
Do you have any tip for me?
Thank you

Hi @carlowahlstedt, @damccorm
Sorry to bother you. I solved my issue.
I tried locally with nodejs the snippet
fs.utimes(file, new Date('1999-01-01T00:00:00.000Z'), new Date('1999-01-01T00:00:00.000Z'), (err) => {
console.warn(Problem applying the timestamp: ${err});
});
In windows the snippet works but emit the warn.
In my pipelines, so, the message
Problem applying the timestamp: undefined
Problem applying the timestamp: undefined
is a false negative.
The function apply correctly the file timestamps.
My issue was another. And I think could be very useful also for all users that google "Problem applying the timestamp: undefined|null" and probably have the same issue/usecase.
My issue was GIT. I was trying to copy static assets from GIT repo preserving the timestamp to reduce the release time using Windows Machine File Copy step (robocopy skips copy when file have same timestamps and size).
GIT doesn't preserve files timestamps. Every time you clone a repo you have files with timestamps now().
I solved my use case (release a big legacy monolith with almost 30k files in 8 different machines) using a Python Script step running this
https://github.com/MestreLion/git-tools/blob/master/git-restore-mtime
on $(Build.SourcesDirectory) as a first step in the pipeline.
C:\hostedtoolcache\windows\Python\3.7.9\x64\python.exe D:\a\1\s\DeployUtilities\scripts\git-restore-mtime.py
35,728 files to be processed in work dir
Statistics:
15.78 seconds
37,373 log lines processed
50 commits evaluated
6,017 directories updated
35,728 files updated
The script apply to all GIT source files the last modified date using git logs. And is very quick.
After this step the Copy files step with preserving timestamp options works well and I now I have artifacts with the "static part" with fixed/logical dates and when I release I don't have to wait 2 hours but few minutes.
I hope I have helped someone who comes here
Thank you

@sheltertake  I'm glad you were able to find a resolution. In the future I would recommend opening a new issue for something like this. Additionally, while you are doing that, I would also recommend that you add the detail from your second comment on from the beginning. Troubleshooting for your original comment would have been literally impossible. 😁
Also, as it pertains to assets to be released, you generally do not want aquire those via git. You should use an artifact store (ex. run a pipeline against the asset git repo, publish to azure artifacts). Then during your build process you CA aquire them from that static locations where they will continue to have the correct, original, timestamps.
Hope this helps.


[Bug] TypeError when printing DatasetWithEntities

Summary
TypeError raises when printing a DatasetWithEntities.
Describe the bug
When printing, displaying or representing a DatasetWithEntities next error raises:
TypeError: 'Entity' object is not subscriptable

To Reproduce
from zshot.evaluation.dataset import load_ontonotes

dataset = load_ontonotes()
print(dataset)

Expected behavior
The result should print a summary of the DatasetDict with the splits, columns and number of rows per split.

Type error raised when importing evaluate
TypeError: 'type' object is not subscriptable
obtained while
from zshot.evaluation.zshot_evaluate import evaluate

Hi! Thank you for your comment.
Unfortunately, I'm unable to reproduce the error, when I do import zshot.evaluation it works without any problem. Could you please provide information about the version of Zshot you are using?

Related StackOverflow post
It seems next typing fails with Python < 3.9:
def load_medmentions() -> DatasetDict[DatasetWithEntities]:
This is due to the class DatasetDict of datasets extending dict. dict is a type, and it's not subscriptable in Python<3.9 (for typing it's used Dict, not dict)


http2 vs http1 support seems backwards

Prerequisites

[X] I have written a descriptive issue title
[X] I have searched existing issues to ensure the issue has not already been raised

Issue
So, in everything I've read, but most importantly, the Chrome docs, Early Hints are only supported on http2 and 3. But, this plugin throws an error if I try to set Fastify to use http2.
Is this not backwards? If correct as is, what's the reason we've disabled this on http/2? Thanks all!

Is this not backwards?

It is the choice from Chromium and it does not means Early Hints is not supported in HTTP/1.1.

What's the reason we've disabled this on http/2?

I believe is the complexity of directly write to socket for HTTP/2.

Also we expect that fastify is behind a reverse proxy like Ingress/traefik which resolves a http2 request to http1.1 and vice versa.
Maybe we can transplant http2 from nodejs sourcecode to our plugin?

Maybe we can transplant http2 from nodejs sourcecode to our plugin?

Yes, we can use reply.raw.stream for the reply.

I think we should just use the native functionality: https://nodejs.org/api/http2.html#responsewriteearlyhintslinks.

I think we should just use the native functionality: https://nodejs.org/api/http2.html#responsewriteearlyhintslinks.

We need to provide a compatible layer for node@14 and node@16.
Patching to use additionalHeaders and .socket are needed.
And, if the native one is available, for example<EMAIL_ADDRESS>We should absolutely go into that.

Also we expect that fastify is behind a reverse proxy like Ingress/traefik which resolves a http2 request to http1.1 and vice versa.

That's not necessarily true. A reverse proxy can still use http/2 to communicate to the backend services.

Maybe we can transplant http2 from nodejs sourcecode to our plugin?

That would be a maintenance nightmare.

That would be a maintenance nightmare.

Not really re-invented the wheel, http2 already provide a method called additionalHeaders. We can directly pass the header with additional :status.

My assessment:

modify formatEntry to not add "Link:" when http2
concat the early hints into message not with CRLF but with a comma, no trailing comma
use additionalHeaders instead of write on reply.raw

I am wondering how we can test http2 because undici does not support http2

I am wondering how we can test http2 because undici does not support http2

Use built-in net or http2 package.

created #8  for discussing http2 implementation

Looks like the PR was closed without resolution :-(

Looks like the PR was closed without resolution :-(

Since, Node.js already implemented the writeEarlyHints in both http and http2.
You should use the native function instead of relying this project (unless you are in old Node.js version).

ah, would be useful to document this somewhere.

https://github.com/fastify/fastify/issues/5479


ulr for download windows

The download address doesn't work, also the client tells me there is a new version but the download fails, client version <IP_ADDRESS>
https://appveyorcidata.blob.core.windows.net/rsuter-25659/nswag/1132/g6u1991p1aswnuiu/src/NSwagStudio.Installer/bin/Release/NSwagStudio.msi?sv=2015-12-11&sr=c&sig=9yhRR1Z%2BlwJTDjw66BOUf81YUwepJsjWz47VrR7VW4o%3D&st=2021-05-19T14%3A15%3A37Z&se=2021-05-19T14%3A21%3A37Z&sp=r

Use this link, works for me:
http://rsuter.com/Projects/NSwagStudio/installer.php

@RicoSuter
It redirect to https://ci.appveyor.com/api/buildjobs/dq2cy72sfna1u4hf/artifacts/src/NSwagStudio.Installer/bin/Release/NSwagStudio.msi
but receive a message response:
{"message":"Artifact not found or access denied."}


[Bug]Shell engine  will not append shell-stdout into persisted-log

Describe the bug
Shell engine will not append shell-stdout to the persistent log when executing
Expected behavior
When the Shell engine is executed, shell-stdout needs to be appended to the persistent log
Screenshots

Hi, @casionone @peacewong, would you help review this pr?
Thanks, kelu.

Hi, @casionone @peacewong, would you help review this pr?
Thanks, kelu.

ok thanks


Failed proof isn't reported if function doesn't start with test or testFail

Update: the reason for the proof not being reported as failed is the fact that the function we're proving starts with check, and we only add a constraint on foundry_success predicate if the function name is prefixed with test or fail:
prove.py#404:
    is_test = method.signature.startswith('test')
    failing = method.signature.startswith('testFail')

prove.py#498:
    if is_test:
        if not failing:
            return final_cterm.add_constraint(mlEqualsTrue(foundry_success))
        else:
            return final_cterm.add_constraint(mlEqualsTrue(notBool(foundry_success)))

However, functions with other prefixes are still getting analyzed and reported as passing, which is misleading. I see at least two ways to address it:

throw an error if the function to be proven doesn't start with setUp, test, or fail — we can do that at the --match-test processing stage
add a warning message if the function doesn't start with test or fail

Original issue:
The following test should fail if number equals 99. The failing node has an EVMC_REVERT status, but it doesn't get reported as failing and the proof is considered passing. At the same time, kontrol get-model generates a counterexample for this node correctly.

As suggested by @RaoulSchaffranek, a nice way to address this issue is to introduce a different success predicate for functions not starting with test and testFail, e.g., assert that there is no reverting path.


SHEncoding seems wrong for torch implementation

Describe the bug
I do a test SHEncoding for implementation 'tcnn' and 'torch', but they get different results.
To Reproduce
Run the following python script.
import torch
from nerfstudio.field_components import encodings

def test_tensor_sh_encoder():
    """Test Spherical Harmonic encoder"""

    levels = 3
    out_dim = levels**2

    encoder_torch = encodings.SHEncoding(levels=levels, implementation='torch')
    encoder_tcnn = encodings.SHEncoding(levels=levels, implementation='tcnn')

    in_tensor = torch.ones((1, 3)).cuda() *2
    encoded_tcnn = encoder_tcnn(in_tensor)
    encoded_torch = encoder_torch(in_tensor)
    print(encoded_tcnn.float())
    print(encoded_torch)

Expected behavior
you will get the following result:
tensor([[ 2.8198e-01, -1.4658e+00,  1.4658e+00, -1.4658e+00,  9.8359e+00,
         -9.8359e+00,  8.2031e+00, -9.8359e+00,  5.9605e-08]], device='cuda:0',
       grad_fn=<ToCopyBackward0>)
tensor([[0.2821, 0.9772, 0.9772, 0.9772, 4.3702, 4.3702, 3.4693, 4.3702, 0.0000]],
       device='cuda:0')

Additional context
I think the torch implementation doesn't align with the description of Appendix A2 Polynomial Forms of SH Basis.
the torch implementation is(https://github.com/nerfstudio-project/nerfstudio/blob/main/nerfstudio/utils/math.py#L57):
components[..., 1] = 0.4886025119029199 * y
components[..., 2] = 0.4886025119029199 * z
components[..., 3] = 0.4886025119029199 * x

but the tcnn implementation is(https://github.com/NVlabs/tiny-cuda-nn/blob/master/include/tiny-cuda-nn/common_device.h#L348):
data_out(1) = (T)(-0.48860251190291987f*y);                               // -sqrt(3)*y/(2*sqrt(pi))
data_out(2) = (T)(0.48860251190291987f*z);                                // sqrt(3)*z/(2*sqrt(pi))
data_out(3) = (T)(-0.48860251190291987f*x);                               // -sqrt(3)*x/(2*sqrt(pi))

the tcnn implementation is aligned with the description of Appendix A2 Polynomial Forms of SH Basis:

components[..., 1] and components[..., 3] are should be a negative value.
Another difference is that tcnn has a preprocess for the directions input:
torch implementation:
x = directions[..., 0]
y = directions[..., 1]
z = directions[..., 2]

but the tcnn is:
x = data_in(0, i) * 2.f - 1.f,
y = data_in(1, i) * 2.f - 1.f,
z = data_in(2, i) * 2.f - 1.f,

The torch version is known to be wrong. I was planning to send a fix but get directed to focus on other things.


Broken RequireJS support

This states that it checks for define while using undefined.
https://github.com/amplitude/Amplitude-JavaScript/blob/40ff69f0870b43c2cd0fc97c6f7e738272ed62cf/amplitude.js#L17
Later undefined is called as if it's define
https://github.com/amplitude/Amplitude-JavaScript/blob/40ff69f0870b43c2cd0fc97c6f7e738272ed62cf/amplitude.js#L910

Hi @mykola-adbeat, This should be fixed in version 5.0. It turns out the JSON polyfill module we were using didn't get along RequireJS/UMD.


Fixes #10120: Use correct repository definition in pom.xml

https://www.rudder-project.org/redmine/issues/10120

OK, merging this PR


[AVM Module Issue]:  terraform plan -refresh-only fails when called before resources are deployed

Check for previous/existing GitHub issues

[x] I have checked for previous/existing GitHub issues

Issue Type?
Bug
(Optional) Module Version
0.3.1
(Optional) Correlation Id
No response
Description
We are using Azure DevOps to deploy our Azure resources. Our pipeline always calls  terraform plan -refresh-only before performing a terraform plan and apply steps. We have had issues with the tfstate file not staying sync with the deployments and this was our workaround. The solution works perfectly for all our remaining pipelines but fails for the AVM route table module. We use AVM modules extensively in our IaC. Here are the details of the actual error we are encountering:
terraform plan -var-file="....\environments\variables.dev_002.tfvars" -input=false -out=tfplan
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: Error in function call
│
│   on .terraform\modules\route_table.azure_route_table\outputs.tf line 18, in output "routes":
│   18:   value = zipmap(
│   19:     [for route in var.routes : route.name],
│   20:     values(azurerm_route.this)[*]
│   21:   )
│     ├────────────────
│     │ while calling zipmap(keys, values)
│     │ azurerm_route.this is object with no attributes
│     │ var.routes is map of object with 2 elements
│
│ Call to function "zipmap" failed: number of keys (2) does not match number of values (0).

Hey @yrachakonda

Note that the terraform command you posted is not a refresh, just a regular plan
Please include all the technical details and steps to reproduce the error including the terraform code.

@yrachakonda
Please share the required information.

Hey @yrachakonda
Please take a moment to upload all the required information for us to help, without it we cannot debug the issue

Hey @yrachakonda
Closing this issue, feel free to re-open.


test(automation): browser logs separated

Browser logs, that indicate success or failure of test were limited only to the console. Now they get logged to a new log file named browser_logs.log for effective debugging and test status tracking.

Can one of the admins verify this patch?

@rgarg1 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1946-fabric8-planner.int.rdu2c.fabric8.io

@rgarg1 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1946-fabric8-planner.int.rdu2c.fabric8.io

@rgarg1 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1946-fabric8-planner.int.rdu2c.fabric8.io

@rgarg1 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1946-fabric8-planner.int.rdu2c.fabric8.io

@rgarg1 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1946-fabric8-planner.int.rdu2c.fabric8.io

@rgarg1 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1946-fabric8-planner.int.rdu2c.fabric8.io

Kindly merge

@rgarg1 snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1946-fabric8-planner.int.rdu2c.fabric8.io

@rgarg1 the merge option will get enabled after the CentOs build is green.

[test]


engine: Don't modify placement rules if blueprint is reprocessed

Before, if the leader reprocessed the same blueprint (as happens when
the daemon restarts) the engine would sometimes modify the placement
rules in the database. This was because the portPlacements function
made use of the fact that the order of TargetContainer and
OtherContainer doesn't matter:  if there was an exclusive placement, it
would create one rule, using the first referenced container in the given
connections as the TargetContainer. Therefore, if the order of
connections passed to portPlacements changed, the resulting placement
rules might have swapped TargetContainers and OtherContainers. Note that
it's expected for the order to change since the connections are read
from the database, which returns rows in a non-deterministic order.
This commit addresses this problem by creating two placement rules for
each exclusive placement:  one rule for each affected container, with
it as the TargetContainer.
Although this placement swapping didn't result in incorrect behavior in
the current scheduler implementation, it will be problematic in the
Kubernetes implementation. This is because the placement information is
part of the deployment spec we pass to Kubernetes, so if the placement
rules move from one container to another, their deployment specs will
change, and Kubernetes will restart the changed deployments.
Furthermore, defining placement rules for both affected containers will
make the Kubernetes deployment specs easier to debug. Looking at the
placement rules for a given deployment will be sufficient to understand
its placement constraints:  there's no possibility that another
deployment has a placement rule that references the container.

Bleh.  I'll be really glad when we can get rid of our funky placement code and just use Kube's.


Update kubeflow-central-dashboard rock for v1.9.0-rc.2

Context
Each charm in Kubeflow has a ROCK (or a set of ROCKs) it is using. The process of upgrading ROCKs usually means going to the component's upstream repository Dockerfile, comparing current ROCK version against the one in the repository and adding the missing bits.
Note: wait until upstream releases rc2
What needs to get done

Clone the upstream's kubeflow repository.
Go to desired Dockerfile (first line in rockcraft.yaml should specify the full path).
Checkout to the branch or tag of the target version.
Checkout to the branch or tag of the version of the current ROCK.
Compare both files to spot the differences.

Definition of Done

New ROCK is ready.
Tests are passing.
ROCK is published under charmedkubeflow Dockerhub account.

On kubeflow/manifests v1.9.0-rc.2 there were no changes to this image. Nothing else to do.


Hello!About the track speed evaluation

Hello!The running speed of the model in the paper can reach 30~40fps,but when I download the pre-trained model and test it on got10k dataset, tracker.py set time stamps before and after tracking a single frame by referring to the time module, but it is not as fast as described in the paper. Isn't the evaluation of tracking time calculated in this way?

@davidyang180 Hi, to speed up the evaluation on the tracking benchmarks, we run 32 processes in parallel. This can save the "total evaluation time" but would reduce the "speed per sequence". When testing speed, we actually only takes the forward propagation time in account.


Rename type insecureAcceptAnything to accept

Required for pending change in upstream library https://github.com/containers/image/pull/132
Signed-off-by: Aaron Weitekamp<EMAIL_ADDRESS>

Don't we need to get this into skopeo before we ship rhel7.3.1?

We need this in https://github.com/containers/image/pull/132 first, then this can go in. We can stage support in (atomic CLI)[https://github.com/projectatomic/atomic/blob/master/Atomic/trust.py] so it will be backwards compatible.

Is this pull request still something we are considering?

At this point I consider skopeo an "expert" tool so I'm okay just mapping this to 'accept' in atomic CLI or any other tools that call/wrap skopeo.

Then can you close this pull request.


[FEATURE] Making the UI more modern , with so many interactive effects

I want to make something like this
I want to change the css and js to achieve this

@MOHIT-IITP feel free to open a PR

/assign


Squishing the window horizontally causes cropping of messages

When you resize the browser window to become skinnier, there is no responsive design and so the four columns become too small to read.

 Add dynamic columns to prevent text squishing

Fixed in https://github.com/AreYouW/mano-aloe/pull/74


Revert "[Aio] Add AsyncIO support to grpcio-reflection"

Reverts grpc/grpc#22662

Known failure: #22691


coap: Limit packet size to COAP_UDP_MTU when reading from socket

When calling sol_socket_recvmsg with empty buffer, socket will return
the size of packet read. This can be larger than COAP_UDP_MTU when not
using a real udp socket (tinydtls socket wrapper, for example).
This patch also fixes sol_socket_dtls_recvmsg behavior when calling it
with empty buffer.
Signed-off-by: Otavio Pontes<EMAIL_ADDRESS>

@glima Can you test that? It is related to the pr you merged. There was a problem with dtls that I didn't realize at the time

I thought that we would fail if we have a packet that is larger than COAP_UDP_MTU, that's why I did this patch. My bad.
I'll close and send another patch, only fixing the dtls socket behavior.


Demonstrate bug with rotating rounded rectangles.

This demonstrates bug #83 .  Apologies if this is not the best place to put such code, happy to move it if there's a better location.

No worries about the delayed reply, I hope you enjoyed your time away :-) .  I'm traveling right now as well, but I should be able to give a full reply sometime this weekend.

I convinced myself I was advising garbage.
I merged this in https://github.com/go-pdf/fpdf/commit/410632a8467399f5aadb6629d8e60a91f721afa1 (with minor gofmt fixes)
thanks for the PR.

(merged in https://github.com/go-pdf/fpdf/commit/410632a8467399f5aadb6629d8e60a91f721afa1)


CI specification

We need a CI mechanism to check the examples stay up-to-date and to notify us if something goes wrong.
It means launching each example per language in a sequence with pauses, allowing them to finish a certain logical sequence given the dependencies.
Topics to discuss

[ ] What triggers a check

for example, new PR in examples
if possible, Iroha repo's dev branch merge

[ ] Check intervals to react to Iroha codebase changes

It is an alternative to another repo's merge, and I'd prefer to react to a merge in iroha2-dev

[ ] Notification mechanism for the issues

I'm thinking about a Telegram message from a bot on something breaking, telling which example and language it is, and what passed

[ ] Should we separate SDK tests per language or keep a single GitHub action for all languages?
[ ] Scripting language to run the checks

Python seems appropriate despite many issues

I would like to follow these principles:

All examples should target a single version of Iroha
Each example should be written as a test, i.e. it should contain an assertion of the effects it has made. If assertion fails, example execution fails too.
Each example should be isolated, i.e. it shouldn't rely on side effects made by other examples.
Examples should not start Iroha; Iroha should be started and configured externally.
All examples have the same assumptions about how Iroha is configured before their execution

If we follow them, we can achieve some benefits:

Easy to test examples with different versions of Iroha: it will be reduced to simple replacement of the compiled binary
Examples are unified
Isolated examples-as-tests should be good educational pieces of code

The CI of this repo will do the following: on push to the main and/or on PRs, it runs all of the examples using a specified version of Iroha. (Later, we might optimise it and run only those parts that are really updated.) This way, each time we update the examples or the version of Iroha they target, we will see if they all actually work.
The CI of Iroha repo will do the following: On push to the dev branch and/or on PRs, it will build a new version of Iroha, fetch the examples repo, and run all of the examples with freshly built version.
Answering the topics:

What triggers a check: this repo will run the examples on each push/PR. Iroha repo will do the same, when it happens there.
Check intervals to react to Iroha codebase changes: redundant. You open/merge a PR - you see results right away.
Notification mechanism for the issues: redundant, same reason
Should we separate SDK tests per language or keep a single GitHub action for all languages? Not now. We can introduce refined workflows triggering later (it is an optimisation). Since each example is isolated, we can run them concurrently and collect all errors at once.
Scripting language to run the checks: we use Python as a scripting language in Iroha CI, I vote for it.

Let's approach the examples this way; we mostly agree here


allowCORs new feature issues

Expected behaviour
a simple request from a browser should not report a CORs error. I might have it wrong but it looks like like the automatic response to the browsers OPTIONs request worked properly, but the corresponding response from mountebank for the GET/POST requires a CORs header as well. The debug traces shows the OPTIONs got it but the GET/POST did not. The current behavior may be what is planned: add an automatic option but leave adding the header for requests to each individual header. Nothing wrong with that, though I think it would be nice if both behaviors were covered.
...
Actual behavior
from chrome:
Failed to load http://localhost:7400/post-test: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8383' is therefore not allowed access.
...
Steps to reproduce
attached file is the mb configuration. Simple jquery script included as well. Calling the endpoints using POSTMAN succeeds
bug_info.zip
...
Software versions used
chrome on mac
OS         : mac sierra
mountebank : 1.14.0
node.js    : 6.11.1
  (only if installed via npm)
Installation method :
  npm

Log contents in mb.log when running mb --loglevel debug
debug: [http:7400] ::1:50256 ESTABLISHED
info: [http:7400] ::1:50256 => OPTIONS /post-test
debug: [http:7400] ::1:50256 => {"requestFrom":"::1:50256","method":"OPTIONS","path":"/post-test","query":{},"headers":{"Host":"localhost:7400","Connection":"keep-alive","Access-Control-Request-Method":"POST","Origin":"http://localhost:8383","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36","Access-Control-Request-Headers":"x-request-sample","Accept":"*/*","Accept-Encoding":"gzip, deflate, br","Accept-Language":"en-US,en;q=0.9"},"body":""}
debug: [http:7400] ::1:50256 no predicate match
debug: [http:7400] ::1:50256 generating response from {"is":{}}
debug: [http:7400] ::1:50256 <= {"statusCode":200,"headers":{"Access-Control-Allow-Headers":"x-request-sample","Access-Control-Allow-Methods":"POST","Access-Control-Allow-Origin":"http://localhost:8383","Connection":"close"},"body":"","_mode":"text"}
debug: [http:7400] ::1:50256 CLOSED
debug: [http:7400] ::1:50257 ESTABLISHED
info: [http:7400] ::1:50257 => POST /post-test
debug: [http:7400] ::1:50257 => {"requestFrom":"::1:50257","method":"POST","path":"/post-test","query":{},"headers":{"Host":"localhost:7400","Connection":"keep-alive","Content-Length":"0","Accept":"application/json, text/javascript, */*; q=0.01","x-request-sample":"sample","Origin":"http://localhost:8383","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36","Referer":"http://localhost:8383/cors-explorer/cors-explorer.html","Accept-Encoding":"gzip, deflate, br","Accept-Language":"en-US,en;q=0.9"},"body":""}
debug: [http:7400] ::1:50257 using predicate match: [{"and":[{"equals":{"method":"POST"}},{"contains":{"path":"post-test"}}]}]
debug: [http:7400] ::1:50257 generating response from {"is":{"statusCode":200,"body":"{success: 'ok'}"}}
debug: [http:7400] ::1:50257 <= {"statusCode":200,"headers":{"Connection":"close"},"body":"{success: 'ok'}","_mode":"text"}
debug: [http:7400] ::1:50257 CLOSED

Thanks @donhenton I actually came across your tool through the docs and great talk on youtube helped a lot, but the CORS issue is seemingly still prevalent.

Hi there,
Yes there's a workaround. You can implement stubs that respond directly to
the CORS requests. Here's
https://github.com/bbyars/mountebank-in-action/blob/master/ch07/examples/cors.json
a simple example that you can extend.
-Brandon
On Tue, Nov 20, 2018 at 1:06 AM shawnnosaurus<EMAIL_ADDRESS>wrote:

Thanks @donhenton https://github.com/donhenton I actually came across
your tool through the docs and great talk on youtube helped a lot, but the
CORS issue is seemingly still prevalent.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bbyars/mountebank/issues/341#issuecomment-440166803,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAESv_CCa0WUTa-r8uvp_QKbmFhclutVks5uw6nzgaJpZM4SuSfu
.


Consistently pass validation kwargs from StreamField to the top-level block

Fixes #4306 and #5175; supersedes (and incorporates tests from) #5185:
min_num, max_num and block_counts can now be set on the StreamField constructor, allowing definitions like
body = StreamField([
    ('paragraph', RichTextBlock()),
], min_num=3)

where previously it was necessary to use an explicit top-level StreamBlock to hang the min_num argument on. The kwargs on StreamField take precedence over any min_num, max_num, or block_counts meta attributes set on the top-level block (at the class or instance level).
The blank kwarg is also now propagated to the top-level block's required attribute, avoiding the situation (described in #4306) where the former controlled the asterisk on the form field but the latter controlled the actual validation. The default of blank=False is respected - even if blank is omitted - meaning that the initial required meta attribute on the top-level block is always ignored. This matches what the documentation always said was supposed to happen (but actually only happened in the specific setup where you pass a block class: body = StreamField(MyStreamBlock)).
These changes mean that we have to relax the rule that meta properties are considered immutable (because things like StreamField(MyStreamBlock(), min_num=3) need to set min_num on the MyStreamBlock instance that already exists by that point) - the definition of __eq__ on blocks has been tweaked accordingly.

@kaedroho Updated!

@kaedroho Updated!

Merged in df125b165209d4c80082cff5502c4e22dc3ad3fd + parents.

Merged in df125b165209d4c80082cff5502c4e22dc3ad3fd + parents.


Doc modifications

To make the docs flowing from main readme, as well fixing some syntax/semantic things

This change is

/assign @ellis-bigelow

Thank you for your contributions!!

All changes accounted for @ellis-bigelow

So close. Missed a couple.

/lgtm
/approve


Unfolding Animation Slightly Off

When I open or close the cell, I noticed that the unfolding animation is slightly to the left of where it should be. Is there a way to fix this?

idk that my solution will surely help you.
I had set base value to be Compact : any, then i found problems like u.
So, I have set base value to be any : any. And then the animation works well where it should be.

Thanks for the idea, @robin43499 ! I gave it a try, but sadly, it did not fix the issue. May I ask what your constraints are for the views, please?

@jdulb17 I use the constraints as same as the Demo.
I fixed it by doing it in a new storyboard.
https://github.com/Ramotion/folding-cell/tree/master/FoldingCell/FoldingCell

Sorry for the delay guys. I'll close this issue because it seems like it was fixed by latest updates.


Scrolling Fixes - Improvements

Updated app so smooth scroll is temporarily disabled on route changes
Added a transition to the InPageNav component so it smoothly transitions as the nav does
Updated the auto focus on route changes to focus to a sr-only anchor at the top of the <main> content so we don't have to contend with scroll position on route changes.

Also added a quick improvement to PromoCard so the CTA anchor is not a direct flex descendant, making it the expected width of the flow content.


Introduce fail forward upgrade e2e tests

Description of the change:
Follow up to #2728 that adds e2e test cases.
Motivation for the change:
TODO:

[x] Add CSV failed e2e test cases
[x] Swap out Joe's quay bundles with an operator-framework controlled repository
[x] Push through magic catalog update support (add a check for verifying the resources after updating the catalog)

Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive
[ ] Tests marked as [FLAKE] are truly flaky
[ ] Tests that remove the [FLAKE] tag are no longer flaky

cc @perdasilva @awgreene

Closing as these changes were pulled into #2728


Consistent border radius across site

Nothing in our mock-ups had a large border radius.

good, call — agreed


build all features on docs.rs

To build all the docs with features
[package.metadata.docs.rs]
all-features = true

Fix: https://github.com/uutils/coreutils/issues/6442
Documentation:

https://docs.rs/about/metadata

nice, thanks :)


Hitting traversal limit of 2**63

I've been seeing a problem where when I read a message, even if I set traversal_limit_in_words to 2**63, an Exceeded message traversal limit error is triggered almost immediately. This code demonstrates the problem,
test.capnp
@0xa9c85a8491f44b36;

struct Entry {
  f0 @0 :UInt64;
  f1 @1 :UInt64;
  f2 @2 :UInt64;
  f3 @3 :UInt64;
}

struct EntryCollection {
  entries @0: List(Entry);
}

test.py
#!/usr/bin/env python

import capnp
test_cnp = capnp.load("test.capnp")

def test():
  count = 1024
  builder = test_cnp.EntryCollection.new_message()
  entries = builder.init("entries", count)
  for i in range(0, count):
    entries[i].f0 = i
    entries[i].f1 = 10 + i
    entries[i].f2 = 20 + i
    entries[i].f3 = 30 + i

  message = test_cnp.EntryCollection.from_bytes(builder.to_bytes(),
    traversal_limit_in_words=2**63)
  for i in range(0, count):
    assert message.entries[i].f0 == i
    assert message.entries[i].f1 == 10 + i
    assert message.entries[i].f2 == 20 + i
    assert message.entries[i].f3 == 30 + i

if __name__ == "__main__":
  test()

This is what happens when I run test.py,
(venv) plesner@sirius:~/Workspace/temp$ pip list | grep pycapnp
pycapnp (0.5.10)
(venv) plesner@sirius:~/Workspace/temp$ time ./test.py
Traceback (most recent call last):
  File "./test.py", line 27, in <module>
    test()
  File "./test.py", line 22, in test
    assert message.entries[i].f2 == 20 + i
  File "capnp/lib/capnp.pyx", line 1029, in capnp.lib.capnp._DynamicStructReader.__getattr__ (capnp/lib/capnp.cpp:23461)
  File "capnp/lib/capnp.pyx", line 1027, in capnp.lib.capnp._DynamicStructReader.__getattr__ (capnp/lib/capnp.cpp:23367)
  File "capnp/lib/capnp.pyx", line 1023, in capnp.lib.capnp._DynamicStructReader._get (capnp/lib/capnp.cpp:23237)
capnp.lib.capnp.KjException: src/capnp/arena.c++:106: failed: Exceeded message traversal limit.  See capnp::ReaderOptions.
stack: 0x7fdf0cfe6369 0x7fdf0cfea02d 0x7fdf0cf4a38c 0x7fdf0cfc6cd4 0x7fdf0cf8ee46 0x7fdf0cfb6a0c 0x7fdf0cfb740f 0x7fdf0ceab947 0x7fdf0ce3a6fc 0x55caae595d35 0x55caae598d59 0x55caae59adb9 0x55caae59aebf 0x55caae5c7a29 0x55caae5c7c65 0x55caae4b583f

real	0m0.109s
user	0m0.104s
sys	0m0.004s

The key seems to be in lines 20-23 where the code repeatedly accesses message.entries[i] because if you hoist message.entries out of the loop into a local variable there is no problem.

I've run into a similar issue. I think there is a bug in from_bytes, or the type of reader it uses, such that it effectively ignores the traversal_limit_in_words argument. That's what I remember from trying to dig into this last time.
If it ignores the limit, you're stuck with the default of 64MB which would be easy to hit.
As a workaround, can you try to write that message to a file and then read it with
message = test_cnp.EntryCollection.read(<file>, traversal_limit_in_words=2**63) and see if the problem persists?

I'll give that a try and see if it has any effect.
It does puzzle me though that it makes a difference whether you do .entries on each iteration of the loop or just once. As far as I understand the traversal limit both should have the exact same effect.

Each time you evaluate message.entries, you are traversing the .entries pointer. There isn't any bookkeeping to remember if you've followed it before (that would be too expensive), so each time you follow it, it is counted against the traversal limit again. It's a pretty crappy check but I couldn't think of any better way to solve the message size amplification security issues without hurting performance.
Note that each time you traverse .entries, you incur FFI overhead (calling C++ code from Python) and pointer validation overhead, so lifting it out of the loop is a good idea for performance anyway.

I think this is a duplicate of https://github.com/jparyani/pycapnp/issues/116

Yep looks like the same thing. Hopefully someone will land the fix so both issues can be closed.


Switching images to opam 2.1 by default

[ ] set-opam-version.sh 2.1 added to images. It's just sudo ln -f /usr/bin/opam-$1 /usr/bin/opam && rm -rf ~/.opam && opam init -k local -a /home/opam/opam-repository --bare (with error handling!)
[ ] opam-depext needs 2.1 support so that with OPAMCLI=2.0 opam depext package works
[ ] Images have ENV OPAMCLI=2.0 and /usr/bin/opam is /usr/bin/opam-2.1 by default. The root is therefore opam 2.1

This presently blocked on the opam depext part, since there's no compatibility for previous versions. Switching to opam 2.1 will expose some uses to problems with opam's integrated depext on certain platforms.
I propose set-opam-version.sh does a re-init for consistency: it only does fractionally more than opam update would, but it's a more consistent thing to do when downgrading from 2.1 to 2.0.

Are there any updates on this? Since mirage 4 requires opam-version >= 2.1.0 this would be very convenient :-)

Ah, I see in #131 that /usr/bin/opam-2.1 is provided. Maybe the docker hub page can be updated to reflect this? Currently it claims the images come with the latest release of opam.

FWIW mirage expects opam in $PATH to be opam 2.1. Copying opam-2.1 to /usr/local/bin/opam works around this.

yes, most of our CI project all start with:
FROM ocaml/opam:<tag>
RUN sudo ln -f /usr/bin/opam-2.1 /usr/bin/opam
RUN opam init --reinit -ni

There is also a dev version of opam available if you do this:
FROM ocaml/opam:<tag>
RUN ln -f ~/local/bin/opam-dev ~/local/bin/opam
RUN opam init --reinit -ni

A year later, could opam 2.2 be used by default? Or is the "do some ln -f" still the suggested modus operandi?

Doing sudo ln -f /usr/bin/opam-2.2 /usr/bin/opam && opam init --reinit -ni still works and most of our services are doing that.
I see less value in keeping opam 2.0 and even 2.1 around now that 2.2 supports all the platforms we need. I don't think anyone is deliberately using earlier opam versions. @shonfeder


Using Kong on Heroku with Grape

Does anyone have experience running Kong (https://github.com/Mashape/kong) on Heroku with Grape? Is there anything I should be aware of when running Grape on top of Kong?

Don't know of any issues.
I'll close this. Please use the Grape mailing list for questions.


Motor does not withstand much variation to the system voltage

Would like to be able to operate down to at least 3s (11.1v) but the commutation control table is all fixed to operation at about 14v. This will require somehow getting rid of the table, which was a hack to begin with.

This is related to #11


Idea on ProtocolHandler inheritance

Heya,
I had to try this out myself, so at that point I figured it was easier to share code than write out a lot of abstract babble on the upstream PR 😄
I did a fair bit of Python in the past, but it's been years now, so I'm brushing up too. This can be some of the weirdest stuff to adjust to because mixins are just a loosely-defined convention in Python and they're still really inheritance at the end of the day, so the lines get rather blurred. And it's multiple inheritance, which not many common languages have, patterns aren't as familiar.
It's a fairly minor thing, but it was bugging me that EnsimeClient didn't mix in/inherit from ProtocolHandler, because that would express the dependency that does exist and also make EnsimeClient more formally abstract: if you try to instantiate one, NotImplementedErrors will happen for handler methods instead of an AttributeError for missing handle_incoming_response().
When I tried to add it, it wouldn't quite work at first because of the way constructors and super calls were chaining. This change made it work.
When a class doesn't define __init__, it inherits its parent's constructor, but in the context of Python's multiple inheritance, a more apt way to put it might be that it delegates up any chain of parents. So like, EnsimeClientV1(ProtocolHandlerV1, EnsimeClient) now acts like it has EnsimeClient's constructor signature, but if ProtocolHandlerV1 were a mixin useful in other contexts, it could be transparent in those chains too. Kinda fits the duck-typey world of Python I guess.
For a mixin class with no state, this is probably a boon for flexibility generally. When state gets involved then explicit constructors have to be dealt with, as is the case when we get down to the ProtocolHandler base class. It works out here because EnsimeClient explicitly calls super(EnsimeClient, self).__init__() and all of its parents also call up the chain already with the same constructor sig, reaching ProtocolHandler. This pattern gets referred to as "cooperative multiple inheritance"—this article is good, in fact it's linked from the official Python documentation for super referencing how it's novel to multiple inheritance.
So this change makes things less explicit in some ways, but I look at it as deferring decisions about how the hierarchy cooperates. I reckon we'll be doing more refactoring in the future, there's still a lot of tight coupling. And it does make EnsimeClient truthful about a relationship to ProtocolHandler as noted above.
What do you think?

I researched a bit about Python inheritance before starting with the refactor, I read about this "Cooperative Mixin" which is kinda the "Cake Pattern" in Scala world. But in order to use it I was forced to add the same init args EnsimClient has to all ProtocolHandlers despite they don't need/use them, just for them to propagate the args during the cooperative initialization chain. I found it pretty horrible.
TBH, I don't like inheritance at all (I hate it), it complicates the modularity, the reasoning and the testability of things a lot without clear gain. I'd much more prefer to use composition here. Do you think we could really isolate the handler from the client so that we can then decide what protocol (instance) the client should use? Maybe changing the signature of the handlers to not depend on client's internal state.
Another component I envision is a sort of a CommandHandler which attends user actions and turn them into Ensime requests or something along these lines. This way all the component could truly be tested in isolation and the client would be just the simple glue between them to put command handling, server interaction and response handling to work together. This way maybe, just maybe we could limit the side effects to just one component and make the testing of the other really simple, and make the one-harder-to-test limited in functionality.
Any thoughts? is it possible for you or I'm just dreaming?
Thank you so much for the help, I think this PR is more cooperative than Python's inheritance :stuck_out_tongue_winking_eye:

That's good since we might be using the same Python version you did back in these days :smile:

I did a fair bit of Python in the past, but it's been years now,

TBH, I don't like inheritance at all (I hate it), it complicates the modularity, the reasoning and the testability of things a lot without clear gain. I'd much more prefer to use composition here.

The irony is that's what mixins are supposed to be (composition in the trait sense at least), but they're still really inheritance 😳

Do you think we could really isolate the handler from the client so that we can then decide what protocol (instance) the client should use? Maybe changing the signature of the handlers to not depend on client's internal state.

The method signatures are already good for stateless I think (call ID, payload), the pain is all the calls within their bodies to stuff defined on the client class, and that the handlers are pure procedural side effect. This is definitely what I wanted to decouple going forward—I'm not exactly sure how yet design-wise, but I don't think we can go too far with that for the scope of the protocol v2 split PR right now. I don't think the changes we're making leave things any worse for future refactoring efforts…

Another component I envision is a sort of a CommandHandler which attends user actions and turn them into Ensime requests or something along these lines.

Heh, so I've actually been trying to work on a standalone ENSIME client hoping it could be pip install ensime and shareable by ensime-vim and ensime-sublime (and unit tested from the start…). It's not to a state that's ready to publish yet, but this sounds close to one of my big remaining design questions. Would be good to chat more, your ideas may be helpful.
My hope is that it would largely reduce ensime-vim to being nothing but the handlers, almost. I'm modeling all the protocol request and response messages with namedtuple which is pretty similar to a Python case class. A client instance provided by the library would send and return these, but I'm trying to come up with what to do for async calls—accept a callback function, or could/should it provide some kind of higher-level API than that? At least initially I think it'll start low-level and leave the rest to implementors. Maybe we'll come up with patterns in ensime-vim that are general enough to upstream as a higher-level API.
I hope I can make progress on it before ensime-vim refactoring discussion runs very far. This protocol version stuff is already good for helping me think about how it should work for calling code like ensime-vim.
Anyway, back to the topic immediately at hand…

Would be good to chat more, your ideas may be helpful.
Feel free to add me to Hangouts with my gmail address or start a private chat on Gitter if you want. Cheers.


Calculate mean and per residue pLDDT scores of AlphaFold's model PDBs (post-prediction)

Hello,
I've found the lddt script here but am unsure how to implement it outside of the AlphaFold. Recently I've obtained many predictions using a variant of AlphaFold, however it did not include pLDDT scores in the PDB outputs. Is there a way to calculate the scores retroactively using the PDB outputs?
Thank you for any help or suggestions,

If the pdb files come from a non-Alphafold model, any confidence metrics will be output by that other model.
One has to run the alphafold model to get alphafold confidence metrics, since those metrics are the models own measure of its certainty.

If you have the .npz files from the AlphaFold variant, you might be able to build something analogous to pLDDT scores based on that. The pdb simply does not have any of the information needed to estimate error in a quantified way.

The PDB are created by AlphaFold however it's just a Singularity container composed of the ML parts of AF (no MSA, etc). More specifically it's on Summit at OLCF (I asked the question here because things are a bit more active over here.
The output at Summit gives a pkl file and a PDB. The b-factor column of the PDBs contains all zero values rather than pLDDT scores. Any idea why this would not have been calculated or am I just missing something?

The per-residue pLDDT values are stored in a numpy array within the .pkl output!


checkpath: cannot stat /run: value too large for datatype

First things first: this is an edge case on 486-era hardware. I would like suggestions for a workaround, but I understand that there might be little reason for a source 'fix'.
With that out of the way, I'm trying to set up Gentoo with OpenRC for testing a cpu identification program on 486 and Pentium level hardware.
On most Pentium-level hardware, OpenRC loads without issue.
On the 486-platform Pentium Overdrive (Pentium in 486 socket), and other 486 chips, OpenRC doesn't load, but errors out after mounting /run.
I get these errors:
checkpath: /run/openrc: unable to stat run: Value too large for defined datatype
checkpath: /run/lock: unable to stat run: Value too large for defined datatype
/lib/rc/sh/init.sh: line 102: /run/openrc/softlevel: No such file or directory

I've tried compiling OpenRC with -Os and -O2 level optimizations, neither made a difference. I've also tried versions 0.54, 0.53.1, and 0.48.

Now, this is interesting, because we definitely need to be building with LFS. But... Meson actually does that for us (rightly or wrongly).
Did you build using muon?
cc @eli-schwartz

Ref. https://github.com/annacrombie/muon/pull/20#issuecomment-1986922001

From what I can see, Gentoo uses meson in the build script.

Can you try to grab the build.log from the build please? ebuild /path/to/ebuild clean install then grab the build.log from /var/tmp/portage? Thanks.

I'll add that as soon as I can.

Build.log (sorry about the color codes)
https://gist.github.com/timw4mail/46deb495542a2093d367cf3630729e5a

I don't get it yet... src/checkpath/checkpath.c does nothing abnormal at a glance and the file was built with -D_FILE_OFFSET_BITS=64.
It's aborting at https://github.com/OpenRC/openrc/blob/3d30b6fddaf92c612deea88d2ced7114ed1fcf9c/src/checkpath/checkpath.c#L116.

Could you share emerge --info too please?

 Note that this can also happen on large inode size (ino_t).
The problem is setting up a test env is a pain. You can do it with tmpfs but you need to force it to use up all the 32-bit inodes numbers first.

Maybe glibc lacks support for 64 bit offsets on i486?
How large is the root filesystem? Try ls -lid /run, is that a huge number?

The root filesystem is 12GB, on ext4.
From ls -lid /run, the largest number I see is 420.

Oh, this is kind of more interesting if we're on ext4, as I don't think it ever has such large inodes (might be wrong). Is your clock right? (What's the value of date and date -u?)

Hmm...so apparently the 486 isn't Y2k-compliant. Any date beyond 1999 and it shows 2094! I set the date to 1999, and the same behavior appears.
I likely have another 486 system that is Y2K compliant, so I'll give that a try.

time_t is 32-bit on these systems and will overflow in Y2038. You can request 64-bit time_t but it's an ABI break. We're working on a transition in Gentoo.
But overflowing beyond 1999 is curious and I'm drawing a blank right now. I will ask around...

dwfreed suggested a theory that coincides with yours - something like the system RTC not being Y2K compliant and Linux handling it terribly..

So I'm able to get OpenRC running on a Y2K-compliant 486 system, so I think the clock time was the issue. I've never heard of a date causing such a fundamental issue, but I'm glad to have solved this silly mystery.


Improved description for memes

It more accurately describes the status of the "Memes" section.

:tada:


Add compatibility for numpy 2 while preserving numpy 1 compatibility

Check the numpy major version number before deciding which file to import methods from.
I have not benchmarked numpy 1 vs numpy 2 performance for outlines, but I have verified that outlines works as intended when using numpy 2 for the examples in the README.
Closes https://github.com/dottxt-ai/outlines/issues/1104

@rlouf Could you please review and merge this PR? Torch has moved to Numpy 2.0 for quite a long time and there might be potential breakages to downgrade Numpy.

Sure, will merge if CI is green.

=========================== short test summary info ============================
ERROR tests/generate/test_integration_transformers_vision.py::test_single_image_text_gen - OSError: trl-internal-testing/tiny-random-LlavaForConditionalGeneration is not a local folder and is not a valid model identifier listed on 'https://huggingface.co/models'
If this is a private repository, make sure to pass a token having permission to this repo either by logging in with `huggingface-cli login` or by passing `token=<your_token>`
ERROR tests/generate/test_integration_transformers_vision.py::test_multi_image_text_gen - OSError: trl-internal-testing/tiny-random-LlavaForConditionalGeneration is not a local folder and is not a valid model identifier listed on 'https://huggingface.co/models'
If this is a private repository, make sure to pass a token having permission to this repo either by logging in with `huggingface-cli login` or by passing `token=<your_token>`
ERROR tests/generate/test_integration_transformers_vision.py::test_mismatched_image_text_gen - OSError: trl-internal-testing/tiny-random-LlavaForConditionalGeneration is not a local folder and is not a valid model identifier listed on 'https://huggingface.co/models'
If this is a private repository, make sure to pass a token having permission to this repo either by logging in with `huggingface-cli login` or by passing `token=<your_token>`
ERROR tests/generate/test_integration_transformers_vision.py::test_single_image_choice - OSError: trl-internal-testing/tiny-random-LlavaForConditionalGeneration is not a local folder and is not a valid model identifier listed on 'https://huggingface.co/models'
If this is a private repository, make sure to pass a token having permission to this repo either by logging in with `huggingface-cli login` or by passing `token=<your_token>`
= 478 passed, 232 skipped, 1 xfailed, 2 xpassed, 4 errors in 720.44s (0:12:00) =

🤔
Will dig deeper into this failure later this week. On the face of it, doesn't seem related to the numpy change

It's completely unrelated so I'll go ahead and merge. Thank you for the contribution!


How to verify whether a call to require actually happened?

I am using mockery to mock some modules. Now I have a special case where I just want to know whether a call to require with a specific module happened or not. As this has no side-effects that are visible from the outside, I can not test any specific behavior.
Basically I just need to know if require was called with parameter foo or not.
How could I test this?

Wouldn't Sinon make this possible?
it("calls the original function", function () {
    var moduleSpy = sinon.spy();
    mockery.registerMock('foo', moduleSpy);
    // do whatever should cause `require('foo')`
    assert(moduleSpy.called);
});

Simply requiring a mocked module doesn't execute the spy. It returns the spy. So in this case, called would still be false.
It would be neat to have the ability to ask mockery if a mocked module was required.

It wouldn't be too hard for mockery to implement Node's EventEmitter and fire an event every time _load receives a request.
var requireSpy = sinon.spy();
mockery.on('require', requireSpy);

/* do some test code */

// Assert that the "some-module" was required
requireSpy.calledWith(require.resolve("some-module"));


"Next page" navigation fix

Make next button go inside the section when in top-level category

STATUS: Waiting on @randyzwitch's potential changes to using #anchor tags in left sidebar

@randyzwitch do you mean "rebase" specifically? Or is a regular merge OK?
Rebases can get messy, so we're rather avoid that.
So what I'm proposing is just:
$ git checkout left-navigation-fixes
$ git fetch origin
$ git merge origin/main

SG?

Looks good except there's an issue with the Next button for Get Started. I think this is due to Library being an alias for Get Started.

Yep, noticed that as well. Is there a plan to update the contet for that section? Or should we find a workaround in the code for this edge case?


[shutdown] Make sure the logging subscriber shuts down properly

The logging subscriber runs in its own process, and when bigchaindb is stopped we need to be sure that the process is properly stopped. For example, we need to be sure that the process completes reading the socket and writing the log records before shutting it down.

This happened today on IPDB Test Net where BigchainDB did not shut down cleanly and was hung after trying to connect to MongoDB thrice.

Resolved by pull request #2304


Possible bug: Hybrid between two interfaces of a union passes type checking

TypeScript Version:  2.1.1 / nightly (2.2.0-dev.20170228)
Went to StackOverflow with this first and the consensus there seems to be that this is a bug.
Here's my question again for convenience:

Consider a situation where an object can have exactly the FooBar or Baz interface listed below.
interface FooBar {
    foo: string;
    bar: string;
}

interface Baz {
    baz: string;
}

It's my understanding that this "one or the other" situation can be handled by creating a union between FooBar and Baz.
type FooBarOrBaz = FooBar | Baz;

So far so good...
The issue I'm having is that the following object passes type checking:
const x: FooBarOrBaz = {
    foo: 'foo',
    baz: 'foo',
};

Expected behavior: x should not pass type checking. It's neither FooBar nor Baz, but rather a combination between the two.
Actual behavior: x passes type checking.
Playground Example

This is working as intended. The type { foo: string, baz: string } is indeed assignable to { baz: string } because a subtype is free to add additional properties. The thing that is perhaps surprising is that you don't get an error in your example, but you do get an error in the following:
const x: Baz = {
    foo: 'foo',  // Error, excess property
    baz: 'foo',
};

This is because when the target is a union type our excess property checking logic (#3823) only checks that each property exists in some variant of the target. It should perhaps be stricter and check that the source is assignable to at least one variant with no excess properties (which would then error on your example).

@ahejlsberg Ah, okay that makes sense I suppose.
I'm admittedly ignorant as to how much added complexity it would take to add the stricter checking but, intuitively speaking, I would assume the example above to only compile successfully with interfaces having an index signature.
The use-case I had when I ran into this issue was when I was attempting to create a function parameter that accepted two different forms of authentication: One being basic username and password auth (in which case, both of these fields is required), and the other being browser cookie authentication where only a single field is required.
I ended up just creating a union between a BasicAuth interface and string which solved the problem.
Thanks for the education on this.

I'd love to see these stricter checks at some point - any way to work around this issue without changing the types themselves? I'm trying to validate some existing data, and I can describe all the types I need, but the lack of the stricter check lets bad data through.
// no error - this is what I hoped would work
let x: { a: number; } | { b: number; } = {
    a: 5,
    b: 5
};

// errors as expected
x = { a: 5 };
x.b = 4;

// errors as expected
const y: { b: number; } = {
    a: 5,
    b: 5
};

Some relevant discussion of this at https://github.com/Microsoft/TypeScript/issues/12936#issuecomment-284590083


add CONTRIBUTING.md

Task
To ensure others can contribute to this project provide clear instructions for doing so.
Definition of Done
Instructions must include

[ ] a welcoming message
[ ] How to commit code that follows enforced best practices

Out of Scope
Discussion required

Closed via PR (#14)

Closed via PR (#14)


Update SDK to reference well-known endpoint

Currently, the SDK is constructing its own values for the necessary endpoints

Update the SDK to reference the well-known endpoint  according to the OpenID Discovery RFC

From our offline discussion:
Jie Hao: "if our SDK references the well-known endpoint, this means that our SDK will need to make an extra API call which adds more latency for the RP app. I'm not sure if this tradeoff (extra latency for correctness of OIDC endpoints) is worth it given that we control both the SDK and the API server"

Closing this issue because there's no urgent need for us to use the well-known endpoint in our SDK as our team is small and develops all products involved


Add clientName to MasterSlaveServersConfig in SentinelConnectionManager

Fixes what I mentioned in this comment: https://github.com/mrniko/redisson/issues/198#issuecomment-134493830
Checked through client list in redis-cli and it works

Thanks!


qemu: Don't leak file descriptors in case of error

If we take one of the error paths from setupVirtiofsd() after
opening the fd variable, the fd.Close() function is not called.
Fixes: #2683
Signed-off-by: Christophe de Dinechin<EMAIL_ADDRESS>

/test-ubuntu

@jcvenegas was faster than me! ;-)
Adding the DNM label till the fd.Close() comment is addressed.

I think you need to remove line
https://github.com/kata-containers/runtime/blob/7b269ff7aa2d62fe12593ff7040798e6c9bd5d65/virtcontainers/qemu.go#L680

I disagree. First, it's safe to fd.Close() twice, see other comment above. Second, the existing fd.Close() is clearly intended to not leave a useless fd open while you run the loop following it.


feat!: use pub/sub instead of static event stores

This PR is a fundamental rework of logid.
Currently, events are stored in static hashmaps, and the intention was that every crate handles their own map.
This not only creates the problem of ever growing maps if not manually emptied, but is also cumbersome to use.
With the switch to a pub/sub approach, a central static publisher captures all set events, and forwards them to anyone that subscribed to the LogId associated with the event.
This adds greater flexibility, and should reduce the size of the central map assuming there will be less subscribers than events.
Communication between events -> publisher -> subscriber(s) is done via sync channels from the std mpsc module.
Since mpsc does not allow multiple receivers, a new channel is created for every new subscriber.
This tradeoff has been made, since alternative channels offering multiple receivers from crossbeam or tokio were too cumbersome to use.
Alternatives notes:

crossbeam allows multiple receivers, but the first to take the msg wins => this is unacceptable for this use case
tokio watch and broadcast are tailored towards their async runtime, and using them without the runtime was too hard to implement => dependency on a full async runtime for a logging framework is also unacceptable

fixes #5


When Package option is specified, top+work/overlay is not applied

Hello,
I just wanted to rebuild an image with an older config, and I was surprised that the package installation didn't work. As it turned out, the overlay wasn't applied, which enabled it to work.
I've tried removing various options, and when I've removed the package-related options, overlays were applied again.
This used to work, so I guess something broke it in the meantime.
Regards,
-czg

Actually, my problem is different, this might just work fine.
Packages are installed at phase 760.
Overlay is handled at phase 790.
Now, in my setup, I need to add a hosts entry, because the package repo is on a public IP, and from the host system that's not reachable, so I have to tweak it first to make it work. So I'm getting the failures because of this.
Otherwise, it makes sense, because the overlay files are also ought to put in the set up config files, which were installed by the package phase.
I know, my case is a bit extreme, however, I think a small hook, something like custom_prepackage_hook wouldn't hurt, to set up anything that's required within the system. For corner cases.
Any thoughts on it?

Does the _PACKAGE_SITE argument for PackageInit help you here?
Otherwise, you can use strategy_add 750 my_custom_function in your config file to do anything you want before the package installation.  The config file is just another shell script, after all.  This has a small risk that future changes to crochet might someday break it, but this is unlikely.
The current ordering of package and overlay installation is intended to address the difference between the build-time environment and the run-time environment.  (The overlay may install networking config that only applies to the environment where the image is ultimately running and can actually break networking at the time the image is being built.)


Revert/Improve nc_create + NC_DISKLESS behavior

re: https://github.com/Unidata/netcdf-c/issues/1154
Inadvertently, the behavior of NC_DISKLESS with nc_create() was
changed in release 4.6.1. Previously, the NC_WRITE flag needed
to be explicitly used with NC_DISKLESS in order to cause the
created file to be persisted to disk.
Additional analyis indicated that the current NC_DISKLESS
implementation was seriously flawed.
This PR attempts to clean up and regularize the situation with
respect to NC_DISKLESS control. One important aspect of diskless
operation is that there are two different notions of write.

The file is read-write vs read-only when using the netcdf API.
The file is persisted or not to disk at nc_close().

Previously, these two were conflated. The rules now are
as follows.

NC_DISKLESS + NC_WRITE means that the file is read/write using the netcdf API
NC_DISKLESS + NC_PERSIST means that the file is persisted to a disk file at nc_close.
NC_DISKLESS + NC_PERSIST + NC_WRITE means both 1 and 2.

The NC_PERSIST flag is new and takes over the obsolete NC_MPIPOSIX flag.
NC_MPIPOSIX is still defined, but is now an alias for the NC_MPIIO flag.
It is also now the case that for netcdf-4, NC_DISKLESS is independent
of NC_INMEMORY and in fact it is an error to specify both flags
simultaneously.
Finally, the MMAP code was fixed to use NC_PERSIST as well.
Also marked MMAP as deprecated.
Also added a test case to test various combinations of NC_DISKLESS,
NC_PERSIST, and NC_WRITE.
This PR affects a number of files and especially test cases
that used NC_DISKLESS.
Misc. Unrelated fixes

fixed some warnings in ncdump/dumplib.c

Ok, I think this PR is ready to merge.

Thanks Dennis I'll test on Windows and merge!