Lift implementation-only import checking into a request

This diagnostic logic is currently called from finishTypeChecking, however it doesn't need to be delayed until after all the source files have been type-checked, only after they have all had their imports resolved.
It can therefore be lifted into a request that operates on a ModuleDecl, and be called from TypeCheckSourceFileRequest. Being a request will ensure that the pass is only run once across the module.
Eventually we'll probably want to re-do import resolution such that it operates on an entire module. At that point, we'll want to look at integrating this diagnostic logic into it.

@swift-ci please test

@swift-ci please test Windows


How to programmatically switch models?

Quick question: how do I switch the model programmatically (like when running this inside JupyterLab?) Do I need to explicitly unload and reload another model?
Specifying a new model per prompt just runs out of memory, so I assume there ought to be some way to unload the models in Python.

It's supposed to unload and load the models as needed but it sounds like that may not be working. That's probably not super well tested.   I wonder if it's related to running in Jupyter and it would work just as a python script.

I'm restarting the kernel, but every time I try to run a prompt with a second model it fails. The GPUs I'm using only have 8GB, and space seems pretty tight in there via nvidia-smi

There might be more problems. Look what happens when I try using imagine twice in the same session with a second model:
me@gpu:~$ imagine "an engineer coding at a computer desktop, wide angle, intricate detail, artwork by moebius" --width 640 --height 384
🤖🧠 imaginAIry received 1 prompt(s) and will repeat them 1 times to create 1 images.
Generating 🖼  1/1: "an engineer coding at a computer desktop, wide angle, intricate detail, artwork by moebius" 640
x384px seed:423675749 prompt-strength:7.5 steps:15 sampler-type:k_dpmpp_2m
Loading model /home/me/.cache/huggingface/transformers/24bd254e54b30e83bcbc15efae29f0ef55256fd144823a9437f5956e594f6803.dcd6f0dd97c55495efb8393e64f704f3f398d695965876be0339bf96b93e2b4e onto cuda backend...
100%|███████████████████████████████████████████████████████████████████████████████| 15/15 [00:11<00:00,  1.36it/s]
    Image Generated. Timings: conditioning:0.36s sampling:11.04s safety-filter:3.90s total:16.05s
    🖼  [generated] saved to: ./outputs/generated/000003_423675749_kdpmpp2m15_PS7.5_an_engineer_coding_at_a_computer
_desktop,_wide_angle,_intricate_detail,_artwork_by_moebius_[generated].jpg
me@gpu:~$ imagine "an engineer coding at a computer desktop, wide angle, intricate detail, artwork by moebius" --width 640 --height 384 --model SD-1.5
🤖🧠 imaginAIry received 1 prompt(s) and will repeat them 1 times to create 1 images.
Generating 🖼  1/1: "an engineer coding at a computer desktop, wide angle, intricate detail, artwork by moebius" 640
x384px seed:602625425 prompt-strength:7.5 steps:15 sampler-type:k_dpmpp_2m
Loading model /home/me/.cache/huggingface/transformers/4c1a32af58eeaff9f36410f7ca27e51a8856185c3f05d5b930975a1397914f10.98fc1312797017a8bac6993df565908fd18f09319b40d9bd35457dfa1459ecf0 onto cuda backend...
/usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import fnmatch, glob, traceback, errno, sys, atexit, imp, stat
Traceback (most recent call last):
  File "/usr/local/bin/imagine", line 8, in <module>
    sys.exit(imagine_cmd())
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/imaginairy/cmds.py", line 238, in imagine_cmd
    imagine_image_files(
  File "/usr/local/lib/python3.8/dist-packages/imaginairy/api.py", line 74, in imagine_image_files
    for result in imagine(
  File "/usr/local/lib/python3.8/dist-packages/imaginairy/api.py", line 151, in imagine
    neutral_conditioning = model.get_learned_conditioning(
  File "/usr/local/lib/python3.8/dist-packages/imaginairy/modules/diffusion/ddpm.py", line 797, in get_learned_conditioning
    c = self.cond_stage_model.encode(c)
  File "/usr/local/lib/python3.8/dist-packages/imaginairy/modules/clip_embedders.py", line 49, in encode
    return self(text)
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/imaginairy/modules/clip_embedders.py", line 43, in forward
    outputs = self.transformer(input_ids=tokens)
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/transformers/models/clip/modeling_clip.py", line 722, in forward
    return self.text_model(
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/transformers/models/clip/modeling_clip.py", line 643, in forward
    encoder_outputs = self.encoder(
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/transformers/models/clip/modeling_clip.py", line 574, in forward
    layer_outputs = encoder_layer(
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/transformers/models/clip/modeling_clip.py", line 317, in forward
    hidden_states, attn_weights = self.self_attn(
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/transformers/models/clip/modeling_clip.py", line 209, in forward
    query_states = self.q_proj(hidden_states) * self.scale
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/linear.py", line 114, in forward
    return F.linear(input, self.weight, self.bias)
RuntimeError: CUDA error: CUBLAS_STATUS_NOT_INITIALIZED when calling `cublasCreate(handle)`

Yeah that's an out of memory error.  I likely cause is that there are different clip models, which I am not currently facilitating unloads for.  The new clip model is bigger.   So you should be able to switch between 2.0 models in the same session or 1.0 models in the same session - but not both.

I don't think I want to invest a lot of time in addressing this so I'll probably just add a warning about this limitation.

A way to unload everything and reset the GPU would probably be enough…On 26 Nov 2022, at 19:36, Bryce Drennan @.***> wrote:
I don't think I want to invest a lot of time in addressing this so I'll probably just add a warning about this limitation.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

I ran into this as well on my computer which means it's gonna be a priority now :-)

I'm encountering this issue as well on google colab. I've tried completely deleting the runtime and trying again but still cannot get the image to finish generating before the RAM is fully allocated and it crashes.

Fixed in 7.1.1


New modals

One finer detail that is UX related; if the user has 0 ZTG the UX could be improved a bit I feel. It might be helpful to have some sort of message/CTA to let the user know where they might be able to get some ZTG

One finer detail that is UX related; if the user has 0 ZTG the UX could be improved a bit I feel. It might be helpful to have some sort of message/CTA to let the user know where they might be able to get some ZTG

Sure, we can add a design ticket for this

closes #605


Why is everything in fetcher deprecated?

What do we use instead?

Support for fetching is deprecated in CrawlerCommons and will be removed
eventually.
You can still use our fetcher with a release of CC which supports fetching,
or try a fetcher from an other 3rd party
Maybe use the apache httpComponents or something else.
Sorry
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
This
email has been sent from a virus-free computer protected by Avast.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Sat, Jan 9, 2016 at 11:43 AM, ThePixelPony<EMAIL_ADDRESS>wrote:

What do we use instead?
—
Reply to this email directly or view it on GitHub
https://github.com/crawler-commons/crawler-commons/issues/113.

See discussion about this as part of issue #92.
Also it's better if you can use the mailing list at https://groups.google.com/forum/?fromgroups#!forum/crawler-commons for questions (like this one), versus filing an issue.

Oh, I see, thanks. Apologies. I'll use the mailing list if there's a next time.


Support array indexing on pointers

Is your feature request related to a problem? Please describe.
Array indexing is only supported on constant length arrays. I can't think of any reasons why we can't let users index through a pointer as long as the pointer isn't void *.
Describe the solution you'd like
Support array index through pointers.
eg.
$p = (uint32 *)arg0;
$val = $p[5];

Describe alternative solutions or features you've considered
You can currently workaround it by doing pointer math and printing individual elements.
Or you can declare a dummy struct with a constant length array, eg:
struct Foo {
  uint32_t arr[16];
}

... {
  $p = (struct Foo *)arg0;
  $val = $p->arr[5];
}

+1 but this links to #1507 as there was some discussion there on what pointer arithmetic means, this is just syntactic sugar for it.

This should be quite straightforward to do, the only drawback is that we won't be able to do array bounds checks on pointers.
I can do this, as I recently did some work on array indexing, but as @fbs points out, we should maybe wait until the discussion on pointer arithmetics is finished.


Sous deploy -repo tag

I couldn't reproduce the issue described in a test - if you note the tests
added to cli_test.go, you'll see that testing with and without -repo produces
the expected behavior.
Along the way I noted that sous update (which should perhaps properly be
moved to plumbing) will automatically perform a manifest creation, in a way
that is similar to, but separate from sous init. Given that manifests cannot
be deleted (at the moment, it's a git operation that requires rebooting all the
running sous servers), creating them automatically seems like a problem to me.
I've removed that option, with a warning to sous init.
Finally, I started to see how the StatusPoller doesn't quite align with other
tools that read from the git context. This bears more discussion, but part of
the upshot is that the poller (and therefore deploy) does respect the
workspace git context, then the interface to e.g. wait for a completely stable
cluster becomes harder.

Current coverage is 61.47% (diff: 58.33%)

Merging #305 into master will increase coverage by 0.12%

@@             master       #305   diff @@
==========================================
  Files           148        148
  Lines          7507       7502     -5
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           4606       4612     +6
+ Misses         2533       2521    -12
- Partials        368        369     +1

Powered by Codecov. Last update 88a049d...8cbeab3

Thanks for adding the test, apologies for the erroneous bug report, it seems some TeamCity config didn't get updated when I thought it had been.

Re 'sous update' being a plumbing command: sounds reasonable, and also makes sense to remove that 'sous init' mimic from there.


[WIP][DO-NOT-MERGE] Merge sdk-quota branch with upstream changes.

Smoke test for builds before doing the actual merge.

Tested merge, have fix for hdfs failure. Closing this PR.


Faster Code

As You have made changes to all SQL Basic Select to improve it, I did not see a change here so I am suggesting it.
select distinct city from station where not right(city,1) in('a','e','i','o','u')  is faster

Thanks for bringing it to my notice. Could you raise a pull request, I don't remember the file at the moment. I can merge the PR if it looks alright


My manatee icons did now come out as square icons!t

How to reproduce:
./edxapp-icon.generator.sh 1200×675-image.png /location/to/save/icons"
Actual dimensions:
29x16
58x33
87x49
etc...
Expected dimensions:
29x29
58x58
87x87
etc...

@BenjiLee Thank you for report, I'll try convert rectangle image to square image using imagemagick.


Text Overlaps the placeholder

The text entered overlaps the place holder :- please refer attachment for details
To reproduce :-

Clear all the tect from the thext editor pane so that the placeholder shows.
Click on the blod or italic button.
Type in some random text without space.

me tooo

Hi team
Any Update on this issue?


3.0 throw EOFError: Ran out of input, but works in 2.0

The code before 2.0 works well. But in 3.0, I try to run submit-pre-training.py and submit-fine-tune.py both give me this error. I try to change the job_type in the former version of submit.py, which also doesn't work.

Did I miss anything need to do before run these 2 python scripts?

Try again, it should work now.
The program was trying to read the QSAR model specified in defaults.py under the "QSAR_models" key in the parameters dictionary. It does this in constants.py, but I have changed it now so that it only tries to load a QSAR model during a fine-tuning job. In that case, it will try to load the models specified in the parameters dictionary, I have left the following path as an example in defaults.py:
"qsar_models"         : {"drd2_activity": "data/fine-tuning/qsar_model.pickle"},

but if you do want to use it you will have to download the QSAR model (from https://github.com/pcko1/Deep-Drug-Coder) to the specified directory before running the code. This path can also be modified in submit-fine-tune.py
Does this answer your question?
Sorry, I have not gotten around yet to writing an RL tutorial for GraphINVENT... but I hope to soon!

I got this new bug and I solved it by changing from torch.Tensor to torch.tensor.


[Features Request] Implementing: "Autosave" or "Persisten Buffers" or a "Recovery Session"

Dear Zyedidia,
I use Micro on a daily base and this has never been happened before but I lost a saved file.
Here is the thing I have the habit to save multiple times during my typing, yesterday I typed an important document and I am pretty convinced to have saved it several times, as usuak, but since it was on a webdav folder, and the connection is flaky, last time I saved I may closed Micro too early and get the file lost.
It would be nice to avoid such extreme edge cases if Micro can have a silent and local autosave function (as many other editors do) in order to have at any new session the last session you had, regardless if the previous session was closed gracefully or not. This function should be smart enough to get the files from their own path and ask to recover the file from the local copy only when this is missing (moved, renamed, deleted etc...); or if the local file is updater than the original;  I think this might mitigate any case where for some reason a file is not saved properly.
Best regards,
Cicorione

Micro does have an automatic backup system. The backups should be saved in ~/.config/micro/backups, although they are by default meant for recovery in case of crashes, and as such backups are removed when micro exits. If you try to open a file which has a backup, micro will ask if you want to recover it.
You can prevent this by enabling the permbackup option. In this case you are responsible for managing your backups (they will never be removed by micro, and will never be auto-recovered), but it gives you maximum flexibility. Backups are saved every 8 seconds (only when actively editing) in a background task.

@zyedidia Thank you!
As a matter of fact I saw every time the recovery function, as I wrote this was an edge case. But what if you close without saving a document it will be available on the backups if you enable the permbackup function?
Thanks again!

Yes if you enable permbackup then the file will be available as a backup even if micro closes normally. It will be in ~/.config/micro/backups. Note: the backup will only be created 8 seconds after the first edit.


fixes https://github.com/fabric8io/fabric8-platform/issues/81 to use internal gogs/gitlab URLs to avoid common errors on DNS/firewalls/ip6

ok to test

[merge]


Add zips for testing Unix permissions

These zips will be useful for testing out behavior around zips created using info-zip that carry permission info in their external attributes field.
related to #https://github.com/dotnet/corefx/issues/17067
@stephentoub

Thanks Stephen!


code ionic view not working

Hi !
The project in the repository of ionic view , is public ?
Because i cant download with this code bd1b6d71.
Thnks

I just tried it and received a message saying there were no public channels for this app.

I am having the same problem

Thanks for opening this issue. Ionic View has been shut down, for that reason I will be closing it.


Added test for issue #338

See issue 338 for more information: https://github.com/mimshwright/pixi-tagged-text/issues/338

Hey Sam, I appreciate the quick turnaround for the test. When I said to write the test and make the PR, I meant that you would also do the fix in your PR. I am sorry for not being more clear.
If you want to include the solution, I'll take a look at it. The issue is most likely in tags.ts. If that's outside your power, that's okay but it could take me a while to get to it.

Added a fix; turns out it wasn't the Regex but erroneous use of String.split. Fixed, and now it passes the test.


Transform object keys broke getter property

Expected Behavior

Preserve the get syntax semantic.
Current Behavior

The getter property converted to function when --transform-object-keys true enabled.
Steps to Reproduce

Obfuscate the following source code
"use strict";
const agents = {
    get http() {
        return 'http';
    },
    get https() {
        return 'https';
    },
};

by cli command line
javascript-obfuscator lib/http/test.js --output lib/http/test.bin.js --compact false --transform-object-keys true

got the following output
const a0_0x3677 = [
    'http',
    'https'
];
(function (_0x257c1e, _0x3677f0) {
    const _0x414abf = function (_0x31802c) {
        while (--_0x31802c) {
            _0x257c1e['push'](_0x257c1e['shift']());
        }
    };
    _0x414abf(++_0x3677f0);
}(a0_0x3677, 0x101));
const a0_0x414a = function (_0x257c1e, _0x3677f0) {
    _0x257c1e = _0x257c1e - 0x0;
    let _0x414abf = a0_0x3677[_0x257c1e];
    return _0x414abf;
};
'use strict';
const a0_0x2057e1 = {};
a0_0x2057e1[a0_0x414a('0x1')] = function () {
    return a0_0x414a('0x1');
}, a0_0x2057e1[a0_0x414a('0x0')] = function () {
    return a0_0x414a('0x0');
};
const agents = a0_0x2057e1;

Your Environment

Obfuscator version used: 1.10.0_2020-08-13T23:26:38.945Z
Node version used: v14.8.0

PR with the fix https://github.com/javascript-obfuscator/javascript-obfuscator/pull/709

Released as 1.10.1

It works now! Many thanks! 👍


Track subgraph processing status

In addition to having a block pointer, each subgraph could have a "status" indicator. This would have a few benefits. First, we don't currently have a way to detect whether a subgraph has hit an unrecoverable error, other than by looking at the logs or noticing that the subgraph block pointer has stopped updating.
It would be helpful if a subgraph could enter an "error" state in which processing is halted, which would then be reflected in UIs, monitoring systems, etc.
Second, I'm thinking of tracking whether a subgraph's processing has reached the chain head block at least once. This isn't needed for correctness, but it's helpful from a monitoring perspective to understand why a particular subgraph is far behind the chain head. If a subgraph has just been deployed and it is far behind the chain head, that is a normal situation, but if a subgraph that has already caught up to the chain head once is now many blocks behind, that could indicate a performance problem with the node or an unusual situation with the subgraph.

closed as dupe


Passing "single interface" mode to the FE

@hitnik What's the use case for this?

@hitnik What's the use case for this?

@jboddey  This is done so that the FE is aware of the single interface mode and does not change the internet connection icon, disables the internet interface selection field, and implements a few other related features.


Load chart data with $http

Could you please document how to load $scope.options.data ($scope.amChartOptions) from $http?
I'm requesting the data with a $http.get and assigning the result to it but the chart doesn't get updated.
$http({url:'example', method: 'GET'}).success(function (response) {$scope.amChartOptions.data = response;});
I've seen in the directive that you have some events... Could you give me a hand?

Are you rendering the chart before the http call is completed?
There arent any watchers in place to see if the data object changes, so it would be up to you to handle that. Your best best to do this would be to use the amCharts.updateData event. Something like this:
$http({url:'example', method: 'GET'}).success(function (response) {
    $scope.$broadcast('amCharts.updateData', response, 'MyChartId');
});

Make you are passing the id of the chart as the third argument. This will trigger the chart to reload itself with the new dataset.
I am going to try to find some time to build this directive out some more, which will include a watcher to detect changes in the data object and reload the chart accordingly. For now, your best bet is to use the event.


Add TestRandom to testkit (#623)

I'd like to generalise the check* functions in the spec but could not do it. Any idea?

@jupposessho Awesome work!
Here's an idea to generalize check:
def checkWith[A](data: Data, expected: List[A])(f: Random.Service[Any] => UIO[A]) =
   unsafeRun(
    for {
      ref   <- Ref.make(data)
      testr = IO.succeed(TestRandom(ref)
      make1 = f(testr)
      nexts <- IO.foreach(0 to expected.length)(_ => make1)
    } yield nexts must_=== expected
   )

Thanks @jdegoes, updated the spec.

Copy that. What is the most elegant(or good enough) way to notify the user if the test data break the contract? What do you suggest?

@jupposessho WDYT about making private constructor and having apply or other constructor method in companion object that returns ZIO[Any, InvalidData, TestConsole]?

@jupposessho @LGLO I don't think we need to validate user data, just ensure the "test data" we supply out of the box doesn't violate the contract.

So only the defaults should be changed for the Double, Float and Gaussian?
If we want to validate, it could be a solution:
sealed abstract case class TestRandom private(ref: Ref[TestRandom.Data]) extends Random.Service[Any]
def fromData(data: Data): ZIO[Any, InvalidData, TestRandom] =     // validation IO.fail...      for {       ref        <- Ref.make(data)       testRandom <- IO.succeed(new TestRandom(ref) {})     } yield testRandom
Thanks, @LGLO for the idea.
But I can agree with @jdegoes, if the user want "invalid" data, why not :)

So only the defaults should be changed for the Double, Float and Gaussian?

Yes, that's what I'd do, just make sure our "out of the box" test data satisfies the contract.

I've changed the defaults

@jupposessho Super! Ready to merge as soon as Travis CI passes. Thanks for your work on this!

The pleasure was mine.


live job queue status

It can be hard to glean what the current job queue is just from watching the logs. A more direct view into what jobs are actually running would be nice - an auto-updating view of what's being received, send, cleaned, etc. Can this be pulled out of rq?

On the command line you can run rq info -i 1which updates every second. You see the status of workers and total jobs but won't see what's begin received, send etc. That information should be available in redash.

The new version has a Queue page in the web interface. Still works in progress to some degree but hopefully finished soon.


Fixed bug with getProduct() in class AmazonProduct

As some people encountered also this bug

AmazonReportRequestList
CompletedProcessingDate should be CompletedDate

Added as different commit


Build issue - gtk theme

Hi,
I was attempting to boot strap a new machine with your config and on first boot in the shell "home-manager switch --flake ." is giving me a build error when it tries the generate a theme.
error hash mismatch in fixed-output derivation '/nix/store/5rjyafr6d7f9k1ayr9916fyfm086nfh6-source.drv':
	specified: sha256-0eCAfm/MWXv68bCl2vbVbvgv8DiUH09TAUhoKq7Ow0k=
	   got:    sha256-h5pxL6Z+ZEOgALxm7Hn0aQh0++/8lNURl0ooGJ+cYqg=
error: 1 dependencies of derivation '/nix/store...generated-gtk-theme-paraiso.drv' failed to build
error: 1 dependencies of derivation '/nix/store...generated-gtk-theme-paraiso-fish-completions.drv' failed to build
error: 1 dependencies of derivation '/nix/store...home-manager-path.drv failed to build
error: 1 dependencies of derivation '/nix/store...home-manager-generation.drv failed to build

Also, I don't know if you care, but if you have both colorscheme and wallpaper commented out there's an "infinite recursion encountered" error.
Thanks

It seems materia's submodules caused the hash change, pushing an update to nix-colors right away.


A way to add custom header to CommandLine.Usage

Hello, thank you for a great project!
I'd like to add the custom header to the output of pflag.Usage. I don't really see a way to do it in the current implementation since the header is https://github.com/spf13/pflag/blob/master/flag.go#L921-L922.
It's quite easy with a footer by changing a pflag.ErrHelp = errors.New("test"), and I wonder if there any way to change the header?

I did this by defining a new FlagSet and overriding Usage() in one of my projects; maybe this will help?

I've tried it, but don't remember, why it didn't work.
The workaround, which I've implemented, is tweaking the footer instead with pflag.ErrHelp
https://github.com/innogames/graphite-ch-optimizer/blob/master/graphite-ch-optimizer.go#L178
Thank you for a suggestion, @mckern


Health Endpoint responds incorrectly to group names

Non existent group names for example actuator/health/foo should return 404.

@hananiel is this still an issue?

Yes this is still an issue - it is not causing any failures but is inconsistent with other tools.


feat: add component folder & move component tests within it

Description

While starting off to write tests for the AsyncAPI website , it was decided that the test folder resembles the structure of original website code structure .
This change will improve code readability and provide a modular structure to the code .
.Group the already written component test files into a new component folder.

Related issue(s)
fixes #2096

@reachaadrika kindly resolve these conflicts as soon as possible, so that we can merge this PR.

@reachaadrika kindly resolve these conflicts as soon as possible, so that we can merge this PR.

@akshatnema I can't see any conflicts here

@akshatnema I can't see any conflicts here

Cheers, I resolved them from my terminal 🥂

/rtm


Refactor registry init.

This moves the implementations of core supported features out of
the base context and into explicit targets. This is to ensure that
targets only carry implementations of things they actually
support.

from numba import cuda
import numpy as np

@cuda.jit
def f(x):
    s = slice(1, 10, 2)
    x[0] = s.start
    x[1] = s.stop
    x[2] = s.step

x = np.zeros(3, dtype=np.int64)

f[1, 1](x)

print(x)

prints
[ 1 10  2]

with this PR even though the slicing registry is not installed on the CUDA target - how is it working now? (Not that it shouldn't be, of course!)

RE slicing. Seems like a lot of registries are being populated as a side effect of import. In the case of slicing it's stencil from numba's __init__ which triggers an import chain that reaches it.

RE slicing. Seems like a lot of registries are being populated as a side effect of import. In the case of slicing it's stencil from numba's __init__ which triggers an import chain that reaches it.

The rest of the patches on this PR are to deal with this! They make it so that modules that register lowering implementations are not imported at import time, or at decoration time, but only once compilation starts. The side effect of this is that nothing (not even the NRT) is jit compiled on import, this speeds up import times by about 40% locally. These patches also move all the lowering registrations out of the base context and onto the specific targets, such that e.g. the CPU just registers things it needs and CUDA just registers things it needs.

@stuartarchibald, the only way I can think of to avoid the move for typed.Dict and typed.List is to use PEP562 to redirect the import. I tried it at https://github.com/sklam/numba/commit/8230acbb1554f41369689f287a9afffb8c91c979. Is it valid?

@stuartarchibald, the only way I can think of to avoid the move for typed.Dict and typed.List is to use PEP562 to redirect the import. I tried it at sklam@8230acb. Is it valid?

Thanks @sklam, I think this approach may well work, it's similar to previous shims. As discussed OOB, first Python 3.6 removal is required, will open a new PR for that.

@gmarkall @sklam both your patches are now on this branch, many thanks.

Thanks for the review @sklam.


add a batchmeta unit test

this turned into some significant changes besides the initial test:

dramatically improves API memory management when making batchmeta requests by handling it in the same stream as other data requests, rather than pulling that into memory and then creating another stream based on that. Also simplifies the code significantly.
While testing, noticed that tests could pass when they shouldn't due to not properly waiting for the schema to dereference before beginning tests; hid a bug in argone, now fixed.


Added script to release allocated-but-unassociated elastic IPs on AWS

Like the title says, plus also some documentation about how to use it.
It's a useful script because allocated-but-unassociated elastic IPs on AWS cost money.

Current coverage is 83.98%

Merging #166 into develop will increase coverage by +83.98% as of fa388a8

@@            develop    #166   diff @@
=======================================
  Files             0      19    +19
  Stmts             0     943   +943
  Branches          0       0
  Methods           0       0
=======================================
+ Hit               0     792   +792
  Partial           0       0
- Missed            0     151   +151

Review entire Coverage Diff as of fa388a8

Powered by Codecov. Updated on successful CI builds.


[WIP] Proposed changes to documentation requirements [contrib-doc-mod]

As part of our collective effort to improve MFEM's documentation I'd like to propose modifications to our CONTRIBUTING.md file. I've started by making a small changes to state more precisely what documentation we might like to see with any new classes or member functions. Suggestions or modifications are certainly welcome.

@mfem/developers -- The topic of improved documentation have come up several times recently, and this is a specific step to help with it that I think we should take. Since it is a change that will affect everyone, please speak up and voice your opinion.

A few other things to consider for addition:

In addition to arguments and functionality, document the limitations of methods and classes
Explain not only what a method, but also why (what's the goal/bigger picture)

As it is nowhere explicitly stated I would like to suggest that the documentation of ownership, lifetime and (possibly) invariants should also be required.

Add a note on what is the responsibility of reviewers to check on this during the PR process.

Mention if function is used only internally or also intended to be user-facing e.g. uses in example. In some cases, we can say: "for usage, see Examples 4,5"

Add a note on what is the responsibility of reviewers to check on this during the PR process.

Do we already have these responsibilities listed some place? Did you want this added to the "Pull Request Checklist" in CONTRIBUTING.md?

@tzanio, Do we already have these responsibilities listed some place? Did you want this added to the "Pull Request Checklist" in CONTRIBUTING.md?

These are currently listed here: https://github.com/orgs/mfem/teams/reviewers/discussions/1
Currently only folks on the Review team can see them, but maybe we should make them public and even add them to CONTRIBUTING.md?
What do people think?

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

I like the idea of making the review process public and adding a lot of the contributing requirements to the things that the reviewers are responsible for checking.  I think some kind of a review guide with a checklist would be ideal.  In such a checklist we could put things like:

Do all of the new classes/methods have doxygen comments describing what they do and what their parameters are?
If there is is a new example or miniapp is there a corresponding PR in mfem/web.
If this is a major feature is there an entry in the changelog describing it.

Folks, I updated this PR by incorporating our PR Editorial Proceed (previously private) and several of the suggestions made above.
Please take a look and let me know what you think.

Looks great, @tzanio! Thanks

Thanks for the feedback @tepperly !

Removed the ready-for-review label -- the PR is already in-review.

We will merge this PR at the end of next week (Oct 22).
Please speak up now if you have any concerns!


Multiplexer and dev cli issues

sst v3.0.83

Cannot cmd+click on links in multiplexer - already mentioned in https://github.com/sst/ion/issues/827

Cannot copy multiline strings in multiplexer - when I highlight multiple lines in multiplexer and copy, it copied only one of them

Scroll via 2 finger trackpad gesture on a mac is way too fast which makes it impossible to scroll the same way you do with all other terminals

NextJs app gets restarted from time to time resulting in a mess of processes launched on different ports:

--mode=basic often just hangs and doesn't start anything, while multiplexer works just fine
sst.log

I’m experiencing the same behaviour

hey thanks for documenting this - what terminal are you using?

@thdxr both iterm and vscode embedded terminal behave the same

@thdxr
VScode and iterm 2, with oh my zsh
Same as @alekseyrozh

The inability to click... I thought it was my terminal or OS issue. Apparently not?

That's weird because I use iTerm and clicking is okay for me.

Having this issue as well

let's try to figure out the mode=basic first since that's an escape hatch for the multiplexer not working. next time it hangs can you kill it and run sst diagnostic and send me the zip?

btw can i see the package.json scripts section for your nextjs app?

We don't use nextjs app and have the same issue.
Running sst diagnostic on mode=basic have this message: ✕  No logs found, run a command before generating a diagnostic report
Running with verbose and print-logs hangs when reaching this log:
time=2024-09-06T01:36:59.669+03:00 level=INFO msg="mqtt connected" time=2024-09-06T01:37:00.181+03:00 level=INFO msg="connected to iot"

i am having trouble recreating this so far - is your app small enough that you can help me recreate it?

did find another bug worth trying v3.0.118

@thdxr any updates on this one? the  v3.0.118 still has crazy scroll speed, things don't copy from the multiplexer properly + links don't click

@thdxr Just for curiosity I tried cmd+click on links in turborepo multiplexer with vscode and it works great


Example twiddle appears to be broken

I'm not sure if this is an issue with twiddle itself or some issue with another dependency but it appears that the example twiddle is broken: https://ember-twiddle.com/7ce3446b14f166f04064eba663c0a350
I just get a flash message saying 'process exited before completing request'

Huh, just tried it in chrome on OSX without issue - what browser and operating system are you using?

@sohara a little more research and it appears that on OSX both chrome/firefox work but Safari doesn't. Depending on what browser you are using, we could investigate further, possibly create an issue with twiddle itself

@toranb Sorry I didn't get back to you. I was using Chrome at the time but it seems to be working now. Possibly my Chrome auto-updated in the interim.
Thanks for the response, enjoying ember-redux so far!

@sohara no worries! Glad its working in chrome - I honestly never dev in Safari myself but found it interesting that iOS 10 safari is fine.


Truncated output

Has anyone dealt with truncated outputs due to token limitation?
The main issue is I don't know how to obtain the rest of the output (chunks?), like I would do it using the "Continue" prompt within a chat-like context, if the resulting output has not finished yet.
Any experience with this problem?
Thanks!

@dosu-bot thanks!
One obstacle that comes to my mind with this is, how do I know beforehand the output I'm getting has been truncated? and at the same token, how would I process that truncated output to concatenate the remaining chunks until getting the actual output?
I have understood that I need to deal with a stream firstly but it's not clear in what way I can do that task.

Hi!
I tried the above solution but it's not even getting into the callback so the problem remains the same just logging the truncated response at the end.
Please, give use a some help to narrow down the problem.
Thanks!


Verification in template

When refactoring my solution
I want to store my answers somewhere
So that the program can check against the answer
For example, have a .answers file and, if present, run an assert against this.
This behaviour could also be triggered by an --assert flag or something
This is, of course, not as simple as it sounds, because sometimes the answer is ascii art/numbers

Closed by #58


3070 build shared sample validation release

Motivation and Context
RELEASE artifacts need to go the the releases repository in ons-ci-rm.  SNAPSHOT ones will continue to go to the repository in ssdc-rm-ci as normal.  This is pretty much a copy of what's already been tried and tested for the common-entity-model repo.
What has changed

Changes to the pom file
Added a Git template to make future PRs easier

How to test?

Run a mvn deploy when the release is x.x.x-SNAPSHOT and the artifacts should be pushed to the artifact repository in ssdc-rm-ci (assuming you have the permissions to do so)
Run a mvn deploy when the release is x.x.x-RELEASE and the artifacts should be pushed to the artifact repository in ons-rm-ci (assuming you have the permissions to do so)

Links

https://trello.com/c/d7cWeH4n

 Build and use release artifacts of ssdc-rm-shared-sample-validation (5)


VertexAI now allows to tune codey models

Description: VertexAI now supports to tune codey models, I adapted the Vertex AI LLM wrapper accordingly https://cloud.google.com/vertex-ai/docs/generative-ai/models/tune-code-models

awesome, thanks @cgrotz!


context_processors: Do not render inline previews for realm description.

Fix issue #11889.
Note: I have placed the test in test_signup.py because this issue occurs during login/signup. There probably might be a more apt place to put the test though...

Transient test failure:
ERROR: test_success_to_private (zerver.tests.test_email_mirror.TestEmailMirrorTornadoView)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.6/unittest/case.py", line 59, in testPartExecutor
    yield
  File "/usr/lib/python3.6/unittest/case.py", line 605, in run
    testMethod()
  File "/home/circleci/zulip/zerver/tests/test_email_mirror.py", line 655, in test_success_to_private
    mm_address = self.send_private_message()
  File "/home/circleci/zulip/zerver/tests/test_email_mirror.py", line 612, in send_private_message
    return create_missed_message_address(user_profile, user_message.message)
  File "/home/circleci/zulip/zerver/lib/email_mirror.py", line 113, in create_missed_message_address
    if redis_client.hsetnx(key, 'uses_left', 1):
  File "/srv/zulip-py3-venv/lib/python3.6/site-packages/redis/client.py", line 1999, in hsetnx
    return self.execute_command('HSETNX', name, key, value)
  File "/srv/zulip-py3-venv/lib/python3.6/site-packages/redis/client.py", line 673, in execute_command
    connection.send_command(*args)
  File "/srv/zulip-py3-venv/lib/python3.6/site-packages/redis/connection.py", line 610, in send_command
    self.send_packed_command(self.pack_command(*args))
  File "/srv/zulip-py3-venv/lib/python3.6/site-packages/redis/connection.py", line 585, in send_packed_command
    self.connect()
  File "/srv/zulip-py3-venv/lib/python3.6/site-packages/redis/connection.py", line 489, in connect
    raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error 111 connecting to <IP_ADDRESS>:6379. Connection refused.

This is great, thanks @Hypro999!  I did a quick test of reverting the code change (keeping the new test) and seeing whether the test failed, and indeed it did not, so I think the test isn't quite correct; the URL you picked wouldn't be previewed anyway in the default configuration.  I think you want the URL to be a link to an image to cause a preview with the default settings.

did a quick test of reverting the code change (keeping the new test) and seeing whether the test failed
I'll have to do this before making future PRs (it's a great yet obvious thing that I should be doing).

I've updated my test. When I originally tested it out, I directly ran bugdown_convert (from the shell) on "https://zulipchat.com" and it responded with the same error that was shared in the related issue. Thus I automatically assumed that this would be a good test string. I had no idea that the tests ran under a different context (assuming that that's what's actually happening here). For some reason I couldn't believe it until I used pdb, inserted a breakpoint and manually tried it out myself!
Thanks for letting me know kindly @timabbott, I greatly appreciate it.

Circle CI seems to be having some issues (since only 1 test failed and that to due to server related issues)... I'm going to try force pushing to trigger another build.

Nice, merged, thanks @Hypro999!
I opened https://github.com/zulip/zulip/issues/11929 for a valuable follow-up to this project.


Snap release under a different name

In the documentation it mentions this snap: https://snapcraft.io/aws-azure-login
Unfortunately, this seems to not be valid anymore.
I did a quick search in the snap store and found this one: https://snapcraft.io/sportradar-aws-azure-login
Is it legit?
Thanks

Hi @franciscogouveia
Thanks for the reminder! We've been waiting to get control over the name "aws-azure-login" for a long time. I made a fix for our snap publish job in https://github.com/sportradar/aws-azure-login/pull/168. Waiting for a manual review by snapcraft before it goes public as stable. 🤞  for a quick approval!

As far as I can see, this is fixed (https://snapcraft.io/aws-azure-login is there and last updated in late Jan 2021). Will close this issue.
Thanks!


framework not found Pods_AppName

Trying to archive my app. Totally clean install of src-cordova to avoid any legacy issues.
ld: framework not found Pods_AppName
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Details
My PodFile
# DO NOT MODIFY -- auto-generated by Apache Cordova
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '9.0'
use_frameworks!
target 'AppName' do
	project 'AppName.xcodeproj'
	pod 'AppCenter', '~> 2.2.0'
	pod 'AppCenter/Analytics', '~> 2.2.0'
	pod 'AppCenter/Crashes', '~> 2.2.0'
end

Which SDK version are you using?

0.3.6

Which OS version did you experience the issue on?

Xcode

What version of Cordova, Cordova platforms, Cocoapods, and Ruby are you using?

"cordova-ios": "^5.0.1"

What device version did you see this error on?  Were you using a simulator or a physical device?

Xcode

What third party plugins are you using?

code-push 2.0.7 "CodePushAcquisition"
cordova-plugin-app-version 0.1.9 "AppVersion"
cordova-plugin-appcenter-analytics 0.3.6 "App Center Analytics for Cordova"
cordova-plugin-appcenter-crashes 0.3.6 "App Center Crashes for Cordova"
cordova-plugin-appcenter-shared 0.3.6 "App Center shared code for Cordova"
cordova-plugin-camera 4.1.0 "Camera"
cordova-plugin-code-push 1.11.20 "CodePush"
cordova-plugin-compat 1.2.0 "Compat"
cordova-plugin-customurlscheme 4.4.0 "Custom URL scheme"
cordova-plugin-device 2.0.3 "Device"
cordova-plugin-dialogs 2.0.2 "Notification"
cordova-plugin-file 4.3.3 "File"
cordova-plugin-file-transfer 1.6.3 "File Transfer"
cordova-plugin-geolocation 4.0.2 "Geolocation"
cordova-plugin-inappbrowser 3.1.0 "InAppBrowser"
cordova-plugin-keychain-touch-id 3.3.0 "TouchID and Keychain"
cordova-plugin-network-information 2.0.2 "Network Information"
cordova-plugin-purchase 8.1.1 "Purchase"
cordova-plugin-splashscreen 5.0.3 "Splashscreen"
cordova-plugin-statusbar 2.4.3 "StatusBar"
cordova-plugin-whitelist 1.3.4 "Whitelist"
cordova-plugin-zip 3.1.0 "cordova-plugin-zip"

It looks to me like the Pods_***.framework isn't installed:

Hi @alexcroox , thanks for reporting this. Are you sure the issue relates to App Center SDK?

I couldn't say if I'm honest. The fix if anyone else runs into this was to delete the .framework from the list in my screenshot above.

Looping back to this. This is definitely related to App Center SDK which has the following in appcenter-shared plugin.xml: <pods use-frameworks="true">.
This is apparently an old way of using cocopods and is causing a conflict with Firebase SDK which aparently will not work if the resulting Podfile includes use_frameworks!

Again to anyone else hitting a brick wall with this. If building your project in Xcode, you need to open YourProject.xcworkspace (NOT YourProject.xcodeproj) so both your Cordova app project and the Pods project will be loaded into Xcode.

For me I had to do a "cordova prepare" again to fix it.

Again to anyone else hitting a brick wall with this. If building your project in Xcode, you need to open YourProject.xcworkspace (NOT YourProject.xcodeproj) so both your Cordova app project and the Pods project will be loaded into Xcode.

I have the same problem with Ionic 4. But the build is by console. Please, what I am supposed to do?


Reconcile capitalisation of crime severity score weight table and generated event files

Currently the capitalisation of the matched crime severity score procedure crime_des_CSSweights.csv (column Offence_Description) does not match the capitalisation in the synthetic events generated by the sampler/historic data.
In particular Offence_Description in the above file is all lowercase - and inconsistently capitalised in the event files.
Can these be reconciled? - likely the most sensible option is for both files to use all lower-case. This should be easily accomplished by just changing the case in the event generator.

Example of output from CrimeDes_to_CSS.ipynb.
Note Offence_Description column is lowercase (as specified for string matching).
| Policeuk_Cat | Offence_Group | Offence_Subgroup | Offence_Description | Offence_code | Weight
-- | -- | -- | -- | -- | -- | --
Violence and Sexual Offences | Violence against the person | Homicide | homicide | 1/4.1/4.10/4.2 | 7973.393423
Violence and Sexual Offences | Violence against the person | Violence without injury | assault without injury on a constable | 104 | 15.087613
Violence and Sexual Offences | Violence against the person | Violence without injury | assault without injury | 105A | 27.021083

Key to note this is an issue not of this package but an issue for the output into the ABM (model of supply)

Closing this issue inline with merge #33


Support %Q - number of microseconds since UNIX epoch.

Hi,
I want to create a custom directive to the input specifier of d3.time.format.
Ex: d3.time.format("%Q%Y")
The directive Q needs to be created. How can I?
Thanks....

Moved to d3/d3-time-format#13.


Consider caching at higher level than indexed JSON

Right now, caching happens at the level of compressed indexed JSON IO. Maybe it could happen at the level or stores instead? Would require refactoring in other parts, as IIRC some of them don't use stores and instead use the raw JSON IO directly because they just read and write it unchanged. But maybe they don't need a cache for exactly the same reason then?

Considering how well the cache works and how much time I put in that, there is probably no sense in doing this.


Question about no_tb item group

It looks like the line
items_groups["no_tb"].discard(items_groups["friendly_tb"])

doesn't affect anything. For example,
import friendly_traceback as ft

def test_no_tb_does_not_contain_friendly_tb_items():
    """Verify items from ``"friendly_tb"`` are discarded in ``"no_tb"`` group."""
    no_tb_group = ft.base_formatters.items_groups["no_tb"]
    friendly_tb_group = ft.base_formatters.items_groups["friendly_tb"]
    assert not any(item in no_tb_group for item in friendly_tb_group)

will fail. I'm somewhat curious why since stdlib docs state

Note, the elem argument to the __contains__(), remove(), and discard() methods may be a set. To support searching for an equivalent frozenset, a temporary one is created from elem.

Maybe the stdlib docs are out of date?

The "no_tb" group is largely a left-over historical artifact; I have not really used it since I changed from what I previously called "verbosity levels" (labeled by integers) to this "include" method ... and, I think,  since I added the "suggest" item.
Looking at it, I think it should be replaced by:
for item in items_groups["friendly_tb"]:
    items_groups["no_tb"].discard(item)

This has been fixed.
About the stdlib documentation: one cannot have a regular set inside another set as sets are not hashable. However, one can have a frozenset as an element of another set. If that is the case, then discard can be used with a regular set as an argument to remove a frozenset.   I had to read the explanation a few times to really understand it...

The "no_tb" group is largely a left-over historical artifact

I suspected this, stumbled over this only since the type checker spit an error. Got a bit curious whether there's a contradiction between what mypy reports and what the docs state.

About the stdlib documentation: one cannot have a regular set inside another set as sets are not hashable.

Ah! the docs talk about sets as elements of the target set! This was the key point for understanding this, thank you!

Actually, after doing a quick search, I found out why I kept the no_tb
option around.
I hope that friendly_traceback will eventually be included by default in
some editor/ide.  (See for example
https://github.com/mu-editor/mu/issues/963 where this is scheduled for
milestone 1.2)
When I experimented with using ft as a syntax checker, I found that, in
some cases, the traceback should be hidden from the user.
https://github.com/friendly-traceback/friendly-traceback/blob/fc7c9a6c033f42b5c24ad9bdd37f7810e4bc3e39/friendly_traceback/editors_helpers.py#L66
This will need to be explored further if and when it is incorporated in Mu.
I should add the unit test that you had before closing this issue.
On Tue, Jul 20, 2021 at 5:13 PM Oleg Höfling @.***>
wrote:

The "no_tb" group is largely a left-over historical artifact
I suspected this, stumbled over this only since the type checker spit an
error. Got a bit curious whether there's a contradiction between what mypy
reports and what the docs state.
About the stdlib documentation: one cannot have a regular set inside
another set as sets are not hashable.
Ah! the docs talk about sets as elements of the target set! This was the
key point for understanding this, thank you!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/friendly-traceback/friendly-traceback/issues/11#issuecomment-883664519,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEZXQTUNFS2NQJNKAQNCKDTYXKFXANCNFSM5ARBVVQQ
.

Closing this issue after adding a unit test.
Note: I will be adding one more issue/feature to take care of, and then jump to version 0.4.

@aroberge sure, no problem - I have more PRs to come (three I think), but they only add more type hints and don't affect the runtime, so can be added any time later.


Test against latest auto-value-moshi (0.4.2)

Current coverage is 96.98% (diff: 100%)

Merging #27 into master will not change coverage

@@             master        #27   diff @@
==========================================
  Files             9          9
  Lines           199        199
  Methods           0          0
  Messages          0          0
  Branches         31         31
==========================================
  Hits            193        193
  Misses            4          4
  Partials          2          2

Powered by Codecov. Last update 7239968...588c0cd


fix: how to properly import other contracts functionality with interface

If we take a look at the contract deployed here
https://gnosisscan.io/address/0x30d155478ef27ab32a1d578be7b84bc5988af381#code
you can see it has 1760 lines of code because it imports the whole Stamps contract.
The proper pattern to interact with other SC is to use the interface and declared methods you need to use. For example, with those changes, the Oracle contract when deployed will have 130 lines of code and does exact same thing.
(also this produces smaller bytecode and takes less space on the blockchain)
Passes all the tests and works the same.
I know Gnosis is not so expensive for deployments and this would be much more effective on L1 but this is just a better, cleaner, and more professional code.

I am not informed how CD/CI process works and still waiting for some answers, so apologies if this is not correct. I just wanted to make a proposal about how things could be improved.

I added interface use for all the contracts that can use them. Locally deployment and tests go through. Need to see what is problem with CI.

Nice cleanup. I would recommend avoiding the I prefix in interfaces. My understanding is that there is no such convention in Solidity, and the user doesn't need to know that he is dealing with an interface: https://docs.soliditylang.org/en/latest/style-guide.html#naming-conventions.

yes it's not required but it is considered good practice to prefix your interfaces with I. You will often see defined interfaces like IERC20 etc all having the prefix
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol
Here are some more links and tutorials that also recommend it
https://coinsbench.com/solidity-101-introduction-to-interfaces-in-solidity-8b0bd64eda38
https://medium.com/coinmonks/solidity-tutorial-all-about-interfaces-f547d2869499
Also, there is a practical reason, removing I and naming them the same as contracts will confuse hardhat with the current setup and will throw "cannot find artifact" for deployment scripts.

yes it's not required but it is considered good practice to prefix your interfaces with I. You will often see defined interfaces like IERC20 etc all having the prefix https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol

If a project uses it, it doesn't necessarily mean it's good practice, one can find a number of counterexamples with solid justification.

Here are some more links and tutorials that also recommend it https://coinsbench.com/solidity-101-introduction-to-interfaces-in-solidity-8b0bd64eda38 https://medium.com/coinmonks/solidity-tutorial-all-about-interfaces-f547d2869499

Both of these sources merely state that the convention is to name interfaces beginning with I without any justification or reference to the source.

Also, there is a practical reason, removing I and naming them the same as contracts will confuse hardhat with the current setup and will throw "cannot find artifact" for deployment scripts.

If that's the case, then I would recommend making a reasonable fix.
The interface prefix I comes mainly from languages such as Java and C#. In some other languages, the I prefix is also used to denote the implementation of an interface, not the interface itself. My point is that if we want to follow this convention, there should be a sound justification for it.

yes it's not required but it is considered good practice to prefix your interfaces with I. You will often see defined interfaces like IERC20 etc all having the prefix https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol

If a project uses it, it doesn't necessarily mean it's good practice, one can find a number of counterexamples with solid justification.

Here are some more links and tutorials that also recommend it https://coinsbench.com/solidity-101-introduction-to-interfaces-in-solidity-8b0bd64eda38 https://medium.com/coinmonks/solidity-tutorial-all-about-interfaces-f547d2869499

Both of these sources merely state that the convention is to name interfaces beginning with I without any justification or reference to the source.

Also, there is a practical reason, removing I and naming them the same as contracts will confuse hardhat with the current setup and will throw "cannot find artifact" for deployment scripts.

If that's the case, then I would recommend making a reasonable fix.
The interface prefix I comes mainly from languages such as Java and C#. In some other languages, the I prefix is also used to denote the implementation of an interface, not the interface itself. My point is that if we want to follow this convention, there should be a sound justification for it.

Thank you for the first review :muscle: :smile:
About interfaces and naming, I did read what you linked. Would like to state, that I just showed a few examples, defining interfaces with I is actually standard in solidity.
https://github.com/aave/aave-v3-core/tree/master/contracts/interfaces
https://github.com/Uniswap/v3-core/tree/main/contracts/interfaces
Some more prominent examples here, actually I don't know if any projects don't do it like that. Hmm yes, there are some but they still state it in name, as ChainLink does with "AggregatorV3Interface" for example.
The bottom line here is the strong convention to always name the interface in this ecosystem of contracts, tools, and developers.
About tooling, yes, there is a problem with namespacing in cases where there is for example interface with the name PostageStamp and there is a contract named PostageStamp, hardhat gets broken but it can be fixed. With the use of fully qualified naming in deployments and tests it does work and we can have the same name.
I do agree that it looks nicer without the I prefix but then again solidity tries to be very exact because of possible and costly errors so I do understand that this standard took off just to be more clear.

can we remove the package-lock.json file from version control please?

can we remove the package-lock.json file from version control, please?

I actually use both yarn and npm but more often npm. That being said if we are using yarn for CI then seems it's better to use that and not update the lock file of npm but for yarn.  I will remove it.


Fix arm night

Fixed broken night arming, when using home-bridge to arm the alarm.com system, instead of going into night mode it goes into regular arm stay, this fixes that. Tested on two separate installs with two separate alarm.com systems/logins. This is a part 2/2 to fix this issue.
Dependent on: https://github.com/node-alarm-dot-com/homebridge-node-alarm-dot-com/pull/55

Thanks for the PR, Loomaanaatii! I'll test and merge soon. When you were working on this, did you notice if there were other ways to arm the system besides these?

Thanks for the PR, Loomaanaatii! I'll test and merge soon. When you were working on this, did you notice if there were other ways to arm the system besides these?

Thanks for the PR, Loomaanaatii! I'll test and merge soon. When you were working on this, did you notice if there were other ways to arm the system besides these?

Honestly, I found this way and once I tested it and it worked I stopped looking.  I've been using this version of the code for 4 days now without issues.

Thanks for the PR, Loomaanaatii! I'll test and merge soon. When you were working on this, did you notice if there were other ways to arm the system besides these?

Honestly, I found this way and once I tested it and it worked I stopped looking.  I've been using this version of the code for 4 days now without issues.


Clear/Reset emitted events

What problem does this feature solve?
When building a component and checking for the events emitted by this component we use component.emitted('eventX')[0] and do the tests. On the next test, we build the component again and use the same assertion.
When the component is more complex, it would be better to just reset the emitted event instead of rebuilding the component. This is common behavior on testing libraries for function (sinon.js, Jest, for example).
What does the proposed API look like?
component.resetEmitted() would be enough.
I can try doing it if this is a desired feature.

I'd like this feature to be implemented, meanwhile I'm doing the following to reset/clear the emitted events:
component._emitted[event] = []

Hi! Sorry it took so long for someone to follow up on this.
I see why this is a valid concern, but couldn't this be as easily solved with a factory function? Eg:
const createWrapper = () => {
  return mount(MyComplexComponent, {
    // ... a ton of options
  })
}

Likely you want to reset the entire component, not just the the emitted events? It seems more ideal to have an entirely fresh copy of the component for each test.
What do you think?

Hey @lmiller1990 ! This is an option, and that's how I was doing it, but recreating the component every time is a little over kill if we just want to test a behavior triggered from the same action again and again, for example.
In the case I'm talking about, I'd like to reset just the emitted events, like jest.clearAllMocks() or  sinon's spy.resetHistory().
Sorry I don't have a real use case to send now.

Thanks for the reply.
If there is a real performance bottleneck with recreating the component, I think that is something we should fix. It looks like you can more or less accomplish what you want with something like:
beforEach(() => {
  component._emitted[event] = []
})

For these reasons, I don't think this is something we will be including in Vue Test Utils at this point. If this was to become a feature one day, I'd be in support of a resetComponent method, that would reset everything to the base state. Since that can be accomplished with a factory function, though, this isn't something we will be including.
Thanks for your understanding!

I believe this is something that should be implemented, not only it would be useful, it would also follow the same functionality of other stub/spy test frameworks (which include this for a reason).
We shouldn't be modifying component._emitted[event] = [] directly to achieve this reset functionality...

I am also against this. You should not have to reset the emitted counter. If you do, then this is another test.
End of story.

Consider the following test:
  it('can be disabled', () => {
    const wrapper = mount(ActionButton)
    const button = wrapper.find('button')
    button.trigger('click')

    // Expect the button to be active and respond to clicks.
    expect(wrapper.vm.disabled).toBe(false)
    expect(wrapper.emitted('click')).toBeTruthy()

    // Disable the button and expect it not to respond to clicks.
    wrapper.setProps({ disabled: true })
    button.trigger('click')

    expect(wrapper.vm.disabled).toBe(true)
    expect(wrapper.emitted('click')).not.toBeTruthy()
  })

It's a valid use-case to make sure an event gets emitted (or not emitted) based on a prop change.

Tracking how many times emit was called should not be too difficult in a single unit test. Or are you using the same wrapper instance for many tests?
Alternatively, you could have two tests.
it('does emit when enabled', () => {
  const wrapper = mount(ActionButton, {
    propsData: {
      disabled: false
    }
  })
  const button = wrapper.find('button').trigger('click')

  expect(wrapper.emitted('click')).toBeTruthy()
})

it('does not emit when disabled', () => {
  const wrapper = mount(ActionButton, {
    propsData: {
      disabled: true
    }
  })
  const button = wrapper.find('button').trigger('click')

  expect(wrapper.emitted('click')).toBeFalsy()
})

I personally feel messing with the internals of a component during a test isn't not ideal, since that is a behavior Vue does not support (so you are testing against a non production behavior).

I feel like this could be a slippery slope - won't we then need to condition resetData, resetComputed, resetProps as well?
A previous comment said you can just do component._emitted[event] = []. Or say, component._emitted = [] for the full reset. The fact that this feature is already available in a one liner seems like it should be enough - are you just asking for a prettier syntax around component._emitted[event] = []?
If there is a performance issue, related to remounting components, we should definitely look into that, and find out where the bottleneck is.

@lmiller1990 That work around didn't work for me. I don't know why, but it didn't work. I would have to dig into it again to see why it didn't.
I disagree that this has to lead to a slippery slop of resetting the other things. In fact, the other things are already spelled out in different guides as far as I remember.
I think the best way to think of this as being analogous to Spies in jest/jasmine. Why did Jest/Jasmine provide a reset() function on a spy? Why didn't they just say "just recreate the spy. We don't want to provide a way to reset the call counts"? I don't have insight into what they were thinking at the time, but it is exactly the same case as emit. This is something that the component can do over time and you could choose to reset it in the beforeEach().

Persisted state between unit tests is never a good idea - you should always remount your component for every test.
I'm happy to help write some code to reset the emitted events that people can add into the projects (like a plugin). I don't think this belongs in core - the API is already too large and complicated as is. We are already trying to cut back on features for the Vue 3 compat, adding new APIs at this point isn't something I think is ideal.
I think we should consider exposing an API for plugins, that way people can have whatever they want. If you want to try and implement this feature for your project, the code for emitted is here and we log events here. It should be as simple as resetting that array/object.

@lmiller1990
So in your unit tests you never use BeforeAll / BeforeEach? That's what these are for, to do test suite setup.

beforeAll and beforeEach have their place - we use them for global stubs and configure in this library, for example. I personally don't use them for component related setup, because I don't think it's good practice. You are, of course, welcome to use them how you see fit.
I think VTU should be a library for testing the bahavior of components in as close to a production-like environment as possible, not for manipulating component internals. I'm sorry if this is disappointing to you, but I don't see this feature as common enough to justify increasing the API surface. I'd be happy to review code and assist if someone reading this comment feels strongly enough this feature. The code could be used like a plugin with existing projects.

A previous comment said you can just do component._emitted[event] = []. Or say, component._emitted = [] for the full reset.

That work around didn't work for me. I don't know why, but it didn't work. I would have to dig into it again to see why it didn't.

I also had trouble getting that workaround to work. After that line runs, emitted() no longer seems to function.
My team has ended up checking for emitted values by using .pop().pop(). This effectively clears the emitted values.
For example:
    const id = wrapper.emitted().delete.pop().pop()
    expect(id).toBe('A')

However, it will leave an empty array ([]) for that key. So if I test for wrapper.emitted().delete in a later test and am expecting it not to have been called then I have to do something like: expect(wrapper.emitted().delete.pop()).toBeUndefined().

What exactly is your use case? You can't create a fresh component?

Personally, I'm a big proponent of creating a fresh component each time, at least when tests need to manipulate data within the component (e.g. setting props).
I submitted the above comment more so to help other people who find themselves in a similar situation where they are unable to (or unwilling to) create a fresh component.
However, saving time is usually the use case I'm given. Creating a fresh component for each test extends the amount of time it takes to complete the test suite. When running suites with a few tests, not such a big deal, but when running suites with a lot of tests the extra time adds up.


Upgrade zustand to the latest version

Please describe the task that needs to be done
From this pull request https://github.com/KaotoIO/kaoto-ui/pull/1324

Bumps zustand from 4.3.3 to 4.3.4.

This is breaking the unit tests because the createStore has been removed.

This has been a warning since few versions now

Seems it was done previously with PR-1515 by @lordrip :+1:
Can not reproduce it now


Increment version for paloaltonetworks releases

Increment package version after release of Azure.ResourceManager.PaloAltoNetworks.Ngfw

/azp run net - paloaltonetworks - mgmt - ci

API change check
API changes are not detected in this pull request.

/azp run net - resourcemanager - mgmt - ci


Add support for logic in templates

By allowing basic logic in templates beyond what is already supported by the Go standard library (specifically, dynamic links), the user will have the able to link to other pages within their own site without having to know the exact page URL.
This change can make it easier for the user in the case that they change URL format or move to a different base URL. With dynamic links, the user only needs to regenerate their site (in production) or do nothing (if they are using hyde serve).

This might be better accomplished by switching to a template language such as EJS or Mustache/Handlebars.


[DCR] Normalize all expression and add '=' to force expression.

Added StringExpression,ValueExpression, etc. for expression or value access
added a ton of unit tests for the expression stuff
For ambigious expressions (StringExpression and ValueExpression) it will treat as string interpolation unless it starts with =.  "Hello @{world}" ==> "hello world", "=user.foo" => Expression("user.foo")
Added assignment operators so you can assign string expressions to expression properties.
cleaned up dialogs files
Exposed Dialogset to DialogManager so you can register external external dialogs
Added DialogId to BeginDialog to allow you to invoke external dialogs

It basically boils down to how to deal with strings as input:

StringExpression always assumes string interpolation unless prefixed with =, producing a string
ValueExpression always assumes string interpolation unless prefixed with =, producing an object which MAY be a string
ExpressionProperty<T> always assumes strings represent something to be interpreted as the type of T, so always producing object of T.

StringExpression
Interpretation of string is as a string interpolation result unless =.
| Input                         | Result        |
|-------------------------------|---------------|
| "13"                          | "13"          |
| "=13"                         | "13"          |
| "user.age"                    | "user.age"    |
| "=user.age"                   | "13"          |
| "Hello world"                 | "Hello World" |
| "='Hello world'"              | "Hello World" |
| "Hello @{user.name}"          | "Hello Joe"   |
| "=concat('Hello ', user.name) | "Hello Joe"   |

BoolExpression
Interpretation of string is as a bool expression
| Input           | Result        |
|-----------------|---------------|
| true            | true          |
| "true"          | true          |
| "=true"         | true          |
| "user.age > 3"  | true          |
| "=user.age > 3" | true          |
| "bad"           | default(bool) |
| "bad @{bad}"    | default(bool) |

IntExpression
Interpretation of string is as a int expression
| Input                | Result       |
|----------------------|--------------|
| 13                   | 13           |
| "13"                 | 13           |
| "=13"                | 13           |
| "x.y.z"              | 13           |
| "=x.y.z"             | 13           |
| "Hello world"        | default(int) |
| "Hello @{user.name}" | default(int) |

FloatExpression
Interpretation of string is as a float expression
| Input        | Result         |
|--------------|----------------|
| 3.14F        | 3.14           |
| "3.14"       | 3.14           |
| "=3.14"      | 3.14           |
| "x.y.z"      | 3.14           |
| "=x.y.z"     | 3.14           |
| "bad"        | default(float) |
| "bad @{bad}" | default(float) |

ExpressionProperty
Interpretation of string is as a T expression
| Input        | Result     |
|--------------|------------|
| T            | T          |
| "x.y.z"      | T          |
| "=x.y.z"     | T          |
| "bad"        | default(T) |
| "bad @{bad}" | default(T) |

ValueExpression (T == object)
Interpretation of string is as a string interpolation result unless =.
| Input                         | Result      |
|-------------------------------|-------------|
| object                        | object      |
| "13"                          | "13"        |
| "=13"                         | 13          |
| "x.y.z"                       | "x.y.z"     |
| "=x.y.z"                      | object      |
| "='x.y.z'"                    | "x.y.z"     |
| "Hello @{user.name}"          | "Hello Joe" |
| "=concat('Hello ', user.name) | "Hello Joe" |

Pull Request Test Coverage Report for Build 99767

0 of 0   changed or added relevant lines in 0 files are covered.
94 unchanged lines in 12 files lost coverage.
Overall coverage increased (+1.4%) to 79.727%

Files with Coverage Reduction
New Missed Lines
%

/libraries/Microsoft.Bot.Builder/Adapters/TestFlow.cs
1
79.67%

/libraries/Microsoft.Bot.Builder.Dialogs/ObjectPath.cs
1
86.46%

/libraries/Microsoft.Bot.Builder.Dialogs/Prompts/OAuthPrompt.cs
1
56.4%

/libraries/Microsoft.Bot.Builder/Inspection/InspectionMiddleware.cs
1
78.89%

/libraries/Microsoft.Bot.Builder.LanguageGeneration/CustomizedMemory.cs
1
90.48%

/libraries/Microsoft.Bot.Expressions/LRUCache.cs
1
82.93%

/libraries/Microsoft.Bot.Expressions/TriggerTrees/Trigger.cs
1
85.09%

/libraries/Microsoft.Bot.Builder.Azure/CosmosDbStorageOptions.cs
2
75.0%

/libraries/Microsoft.Bot.Builder.LanguageGeneration/Evaluator.cs
2
93.25%

/libraries/Microsoft.Bot.Builder/MemoryTranscriptStore.cs
2
86.09%

Totals

Change from base Build 99635:
1.4%

Covered Lines:
10748

Relevant Lines:
13481

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.Luis.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.QnA.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.ApplicationInsights.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Azure.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Dialogs.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.ApplicationInsights.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Testing.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Configuration.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Schema.dll compared against version 4.6.3
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Streaming.dll compared against version 4.6.3


Address pr#295 review

Address Albert's review of PR #295.
Note: This is a post-commit (pr has since been merged) review.

I think I've addressed all your comments, @awwad I'll go ahead and merge if there are no objections to my latest changes.

Yeah, I think that covers my answers to the stuff Albert pointed out.
I'm supposed to be independently reviewing PR #295, too, right?
I'm looking through whether I see any bad edge cases in the refresh logic around the stuff we talked about with version numbers x expiry. Basically, checking these two comments 1, 2. It's taking me a little longer than it should to be sure - sorry.

Yes, I'd be happy if you could independently review PR #295.


SyntaxError: Unexpected identifier

I have no idea how to fix this error. I could use some help. Its probably something simple but i'm fairly new to this kind of thing.

i have the same error it have no idea what it means i guess im gonna be unlucky and not be able to make a discord bot :(


jacfwd through while_loop

Are there plans for supporting jacfwd for while_loops? Tensorflow afaik supports gradients for backprop'd while_loops. I'm really interested in jax's fwd-mode support as well.

Forward-mode automatic differentiation for while loops is quite feasible (much easier than reverse mode, actually). It just requires that we define a jvp rule for while_loop, which is not hard to do since it's just the original loop executed with dual-number semantics.

We do need to do some AD lattice fixed point business (like we do on the differentiable-scan branch). It might make sense to wait for that branch to land, then reuse those tools.

My rule of thumb is that while_loop constructs can help with compile times (potentially a lot!), but don't help execution times (and can even hurt in some cases). Is that the kind of performance improvement you want, i.e. compile times?

It depends on the scaling of the compile time, if its O(number of iterations in the for loop) then it'd be pretty catastrophic. But otherwise it might not be a big issue.

I think it's worse than that: XLA optimizations tend to make compile times be super-linear in the size of the graph.
Sounds like you do want jvp (and hence jacfwd) through while_loop then.

I've also verified that the compile times are indeed super linear.
For highly efficient fixed-step optimizers, eg. L-BFGS, where we know roughly apriori convergence can happen in say roughly 30 steps, this isn't so so bad. But for long time scale dynamics this is definitely a real mess.
I'm also playing around with differentiating through experimental.optimizers now - super excited to see all the awesome stuff you guys added in there.

Thanks for the report!
We're almost done with a scan primitive, which will be both forward- and reverse-mode differentiable, and includes for-loops and folds as special cases. We can separately make while_loop forward-mode differentiable, likely reusing much of the same machinery, but I suspect that scan will be a very useful differentiable loop structure. Keep an eye out for that!

I'm not familiar with the xla lingo of "scan" - but it sounds promising
I've also just verified that the current implementations of experimental.optimizers.sgd is straight-up differentiable if I just use a vanilla for loop.
https://github.com/proteneer/timemachine/pull/85/files
I'll be testing things like adam/momentum as well later on. It's possible I will be rewriting some of my integrators as jax optimizers once I better understand the internals.

@proteneer I believe you should be able to try out scan now. Please report back with how it goes.

@georgedahl there is something slightly better we can do for jacfwd-through-while-loops, though, so scan doesn't quite close this issue (unless @proteneer doesn't need the slightly-better thing described below).
We can use scan to forward (or reverse) differentiate a while-loop that has a fixed number of iterations (aka a for loop) by writing something like this:
from __future__ import division

from jax import lax
import jax.numpy as np

def fori_loop(num_iters, fun, init):
  dummy_inputs = np.zeros((num_iters, 0))
  out, _ = lax.scan(lambda x, dummy: (fun(x), dummy), init, dummy_inputs)
  return out

print(fori_loop(10, lambda x: x + 2, 3))

That doesn't use up any extra memory or anything. But it does require the number of iterations to be known.
In principle we could do forward-mode differentiation of a lax.while_loop without knowing the number of iterations. (And we can reuse a lot of the scan machinery to do it.)
@proteneer does scan work for you, or do you care about the case where the number of loop iterations is unknown?

This looks really cool - I haven't had a chance to play with this yet. In terms of fix iterations, it depends on the application. We anticipate using this optimizers with known trip counts as well as ones that predicate on a test of convergence (eg. on-the-fly detection of SGD convergence).
Let me play with this a little bit first.

For a fixed number of iterations, this was pretty straightforward to implement. Note that I couldn't just set xs to zero since optimizers as written need the iteration count to be provided, so as opposed to allocating a np.zeros((iterations, 0)) requiring O(1) ram, I instead allocated np.arange(iterations) requiring O(iterations) ram.
I've tested JITting both the scan itself as well as its derivative:
https://github.com/proteneer/timemachine/pull/87/files
Timings:
Old version:

real	1m42.888s
user	1m43.148s
sys	0m0.857s

New version:

real	0m4.244s
user	0m5.040s
sys	0m0.373s

Nice! I can probably get away with a fixed trip count for now, though I definitely see a need for variable trip-counts in the future.

Cool! Really great to hear this is useful for you already.
For the iteration count, you might be able to put it in the loop carry, as in (untested):
def apply_carry(carry, _):
    i, x = carry
    g = grad_fn(get_params(x))[0]
    return (i + 1, opt_update(i, g, x)), _
opt_state, _ = jax.lax.scan(apply_carry, (0, opt_state), jnp.zeros((75, 0)))

In general the loop carry (and the input/output) can be arbitrary pytrees, like tuples or nested tuples or dicts or whatever. The scan function will scan over the leading axis of the leaves.

Including iteration count as part of the carry is a much better idea.  Can you open a bug with the repro, and we'll squash it asap?

Filed via #711


[WIP] Add targeted refresh specs

Depends on:

[ ] https://github.com/ManageIQ/manageiq/pull/21582

TODO:

[x] Test no targets
[x] Test existing physical_storage target
[ ] Test existing cloud_volume target

@llivne this is the error you're talking about right? https://app.travis-ci.com/github/ManageIQ/manageiq-providers-autosde/jobs/550423532#L2125-L2142

@llivne this is the error you're talking about right? https://app.travis-ci.com/github/ManageIQ/manageiq-providers-autosde/jobs/550423532#L2125-L2142

@agrare yes this is the error. I cant find the reason for it, I suspect it has something to do with the associations (I think you also wrote about it) but still cant solve it. still working on it...

@llivne check out https://github.com/ManageIQ/manageiq/pull/21582 I try do describe there why those aren't needed in this case

Okay we can test more collections but this is a good start, taking out of WIP

@agrare its look fine by me. do you want me to merge, or you prefer someone else will take a look?

:+1: thanks @llivne go ahead and merge it if it looks good to you


Conflicting cross-version failures for a Java library

Hi,
I've stumbled upon an issue when using a Java library in the build.
Steps
In SBT 1.5.5, given the following build.sbt file:
scalaVersion := "2.13.6"

libraryDependencies += "info.archinnov" % "integration-test-3_0" % "6.1.0"

Running the sbt update would yield:
[error] Modules were resolved with conflicting cross-version suffixes in ProjectRef(uri("..."), "..."):
[error]    info.archinnov:integration-test-2 _2, _1
[error] stack trace is suppressed; run last update for the full output
[error] (update) Conflicting cross-version suffixes in: info.archinnov:integration-test-2

The same build works fine in SBT <= 1.5.4.
Problem
The integration-test-3_0  (Java) library depends on integration-test-2_2 and integration-test-2_1 (see here).
It looks like the fix in sbt/librarymanagement#383 changed the regex in such a way that it catches the integration-test libraries and considers them to be cross-compiled and conflicted. This is obviously not the case as all these are Java libraries.
Is there anything that can be done to avoid this false-positive cross-version failure?
Thanks

Could you try adding the following to your subproject setting?
import sbt.librarymanagement.ConflictWarning

conflictWarning := ConflictWarning.disable

Yes, forgot to mention that adding ConflictWarning.disable indeed fixes the issue. But ideally I would like to avoid turning off this warning for the whole project.
Thanks

Given that Scala 3 has adopted _3 as suffix, and assuming not many other libraries have suffix like _0 or _1, it's a won't fix for me. If you have some idea to resolve this, let us know.

How complicated would it be to make it possible to disable this warning per artifact?
If you that think that it's something that wouldn't require deep changes in the codebase, I'll try to tackle it myself.

It's all in one file https://github.com/sbt/librarymanagement/blob/develop/core/src/main/scala/sbt/librarymanagement/ConflictWarning.scala, but in my opinion it's not worth complicating it, esp if it's for integration testing. Not detecting cross-version conflict could result in a runtime issue, but the runtime of a test is still a test.

Right, I guess I can scope that setting to the test part of the project, and that wouldn't be particularly dangerous.
Great, thanks for the support.

I thought that scoping this setting to Test would be easy, but it seems that my knowledge here is lacking.
Trying to do something like  this:
Test / conflictWarning := ConflictWarning.disable
// or
Test / update / conflictWarning := ConflictWarning.disable

doesn't seem to have any effect.
Am I missing something obvious, or it's impossible to override since the update task is orthogonal to Test?
Thanks

There's only one update per subproject for both Compile and Test, so you'd need to split up to multiple subprojects if you want different setting.

I see, thanks


Not able to publish the code in ASPNET CORE angular js 4 environment

Error getting during publish
The command "node node_modules/webpack/bin/webpack.js --env.prod" exited with code
npm shrinkwrap.JSON UPDATED and there after it not allowing the application to publish
local on debug it is working well

I am not sure if it's specific to ASP.NET Core. If you are getting same issue with AOT mode, please feel free to reopen this issue.


Serif font used on iOS 13 when no font configured

Problem description
When the font configuration is omitted, a serif font is used with TextView on iOS 13. With iOS 12.x and lower, a sans-serif font got used instead.
Expected behavior
Default to a sans-serif font when the font configuration is omitted. This was the default pre-iOS 13 behavior and is also the behavior when no family is specified in the font configuration (see snippet).
Environment

Tabris.js version: 2.8.1
Device: Simulator
OS: iOS 13.0

Code snippet

const {TextView, ui} = require('tabris');

// Create text views with different alignments

new TextView({
  centerX: 0, centerY: 0,
  text: 'Serif on iOS 13',
}).appendTo(ui.contentView);

new TextView({
  centerX: 0, top: 'prev() 10',
  text: 'Sans-Serif',
  font: 'bold 16px'
}).appendTo(ui.contentView);

Cannot reproduce with Tabris.js 2.9 and 3.3.


Node serverless with typescript custom path import errors on now dev

Hi,
I'm trying out Now v2 with Node and TypeScript and got an error below when i tried to import from a custom path which I've specified in my tsconfig :

Strangely when i import an interface from another custom path it works.
tsconfig :

Perhaps is there a way to use tsconfig-paths/register in Now v2 with builders like @zeit/ncc or @now/node?
I'm confused on how Now v2 works for Node serverless structure with TypeScript, was using monolithic tsc and ts-node stack with tsconfig-paths registration previously.
Reproduction repo :
https://github.com/ch4rlesyeo/now-node-server-typescript
Reproduction step :

run now dev
browse http://localhost:3000/api

Note that http://localhost:3000/api/user works fine as its not using custom path.
Thanks in advance.

@ch4rlesyeo posted this on Spectrum as well: https://spectrum.chat/zeit/now/node-serverless-with-typescript-custom-path-import-on-now-dev~4b5fa38a-3016-456c-9fc9-0420e01db0cc

The paths key is not implemented yet. See issue #2832

Closing as a duplicate of #2832


adding devextreme to angular 6 + cli 6

devexteme version:  "^17.2.7",
devextreme-angular version: "^17.2.7",

(tried with 18 too)

Specify the type of the issue (check one with "x"):
[x] bug Report
[ ] feature request
[ ] support inquiry

If I follow the instructions and add the css files to the angular.json, this is what happens on build:

steps to reproduce:
ng new demo
cd demo
yarn add  devextreme devextreme-angular
// open editor and add css files to `angular.json`
ng build

My Angular version:
Angular CLI: 6.0.0
Node: 8.11.1
OS: win32 x64
Angular: 6.0.0
... animations, cli, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.6.0
@angular-devkit/build-angular     0.6.0
@angular-devkit/build-optimizer   0.6.0
@angular-devkit/core              0.6.0
@angular-devkit/schematics        0.6.0
@ngtools/webpack                  6.0.0
@schematics/angular               0.6.0
@schematics/update                0.6.0
rxjs                              6.1.0
typescript                        2.7.2
webpack                           4.6.0

How can I prevent this error?

The root Angular CLI folder is now your project folder. So, you don't need to use '../' any more. We updated the Using the DevExtreme Angular Components with Angular CLI accordingly.

@GoshaFighten Thanks, that got it fixed, but it then directly landed me on: #776
Perhaps it's worth to mention that in the docs too? for the time it's still needed?


sbtools not available for R v.3.6.2?

I get the following warning when I try to install.package "sbtools":
package ‘sbtools’ is not available (for R version 3.6.2)

Hi @katherinejchase -- assuming you have remotes, can you do:
remotes::install_github("usgs-r/sbtools") and see if that does the trick?
I would imagine a new gran build would do the trick as well -- at the end of the day, we need to get sbtools back on CRAN though.

Thank you for your quick response! I used the script from the USGS page and it worked:
install.packages("sbtools", repos=c("https://owi.usgs.gov/R",getOption("repos")))

Ahh. Great. Yes, since sbtools is not on CRAN, the basic install.packages("sbtools") will not work for now.


"Generating single mermaid chart"

Using the current version, I get the following output:
C:\Users\Jan\Documents\throwaway\3130>npx prisma generate
Environment variables loaded from .env
Prisma schema loaded from prisma\schema.prisma
Generating single mermaid chart

✔ Generated Prisma Client (3.7.0 | library) to .\node_modules\@prisma\client in 11.15s

✔ Generated Entity-relationship-diagram to .\prisma\ERD.svg in 8.82s
You can now start using Prisma Client in your code. Reference: https://pris.ly/d/client
```
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
```

Might be that Generating single mermaid chart is some leftover debugging output.
"prisma-erd-generator": "^0.8.0"

I looked through the repo and couldn't find it anywhere. I have seen the same though. I'll leave it open until a version has been tested without it

Then probably something in Mermaid even. Not a big deal fortunately.

It looks like they have some logging levels for their config. I could test it out. Or find a way to hide it. I'll take a look

Fixed in version 0.9.1


Add flannel datapathconfiguration test

Add a trivial flannel chaining CI test for the most basic of validation.

This change is

test-me-please

test-me-please


Deployment stalling during build phase

Occurs during this step. Sometimes there's no error at all.
{ FetchError: request to https://dmmcy0pwk6bqi.cloudfront.net/15e78d181050e8b164f9c5d083d1641355404fb9 failed, reason: getaddrinfo EMFILE dmmcy0pwk6bqi.cloudfront.net:443
    at ClientRequest.<anonymous> (/var/task/worker.js:3659:11)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at TLSSocket.socketErrorListener (_http_client.js:355:9)
    at emitOne (events.js:116:13)
    at TLSSocket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)
  message: 'request to https://dmmcy0pwk6bqi.cloudfront.net/15e78d181050e8b164f9c5d083d1641355404fb9 failed, reason: getaddrinfo EMFILE dmmcy0pwk6bqi.cloudfront.net:443',
  type: 'system',
  errno: 'EMFILE',
  code: 'EMFILE' }

This is fixed by https://github.com/zeit/now-builders/pull/344


Add emailAddress, twitterHandle, description, descriptionXML, _imageURL

Changes required to support columnists

:+1:

:+1:

👍


Possibility: use a pure JS git implementation

Hello, I read this project parses git log shell output.
I recently read about this pure JS git implementation: https://github.com/SamyPesse/gitkit-js
Could it be useful?

Agreed.  The development branch has a version that using node-git, but I'm having an issue with performance and data correctness on large repos with lots of commits.   See also https://github.com/nodegit/nodegit/issues/1068


Handle process.env being undefined in debug func

[x] I understand that this repository is auto-generated and my pull request may not be merged

Changes being requested
Please handle the case where process.env is undefined.
Additional context & links

Thank you @jkarthic !

Thanks @jkarthic , we merged an update to our codegen to reflect your suggestion. It should go out in the next release!

Thank you very much @rattrayalex @dackerman


Clone Children produces duplicates

Expected behaviour and actual behaviour.
We have a simple custom solution for making Questionnaires:

Parent Questionnaire = template
Child Questionnaire = actual questionnaire
Questions of Parent Questionnaire = questions template
Questions of Child Questionnaire = actual questions

So we made a WF, cloning Questions of Parent Questionnaire for every Child Questionnaire created, making Questions of Child Questionnaire
Occasionally, duplicates of Questions of Child Questionnaire are started to occur. There is no system in duplicated creation — 1 question can be duplicated 3 times in 1st Questionnaire, 2 times in 2nd Questionnaire and no duplicated in 3rd
I can provide additional screenshots of WF and duplicated data, but they are in Russian. Don't sure it'll be useful
CRM Version - online/on-premise - WorkflowTools version
Dynamics <IP_ADDRESS> On-Prem
msdyncrmWorkflowTools (<IP_ADDRESS>):Clone Children

sorry miklemiracle, I think I don't understand all the details you shared.
If this is an ocasional issue, and almos all the time works fine, we need to identify what happend on this situations, what could be changed or modified.
I don't have an onprem environment where to test this in any case, so I think the best way is to try to debug it.
best regards.


cource_work

When reporting a bug please provide the following information to help reproduce the bug:
Version of OpenRefine used (Google Refine 2.6, OpenRefine2.8, an other distribution?):
Operating Systems and version:
Browser + version used - Please note that OpenRefine doesn't support Internet Explorer but works OK in most cases:
Steps followed to create the issue:
If you are allowed and are OK with making your data public, it would be awesome if you can include the data causing the issue or a URL pointing to where the data is (if your concerned about keeping your data private, ping us on our mailing list):
Current Results:
Expected Results:

Hi @LisovaOlena, the issue you have filed is empty. I am closing it, feel free to get back to us if you actually have something to report.