Balder/more statically generated compounds in cache 2

@bratseth PR

Yes, but will take this in small steps, by first cleaning up our own usage. and then evaluate what functionality we should keep and what we should drop. Currently there are too many ways to Rome.
There are more in the pipeline.


input: kbd_matrix: add power management support

Add power management support to the keyboard matrix library. This provides a generic pm_action function that changes the keyboard matrix scan in two places when suspended:

reset the state to 0 for all columns
do not enable key press detection

This ensures that any key that was pressed when the device is suspended is released, and no other scan happens until the device is resumed.
--
Tested with the gpio-keys driver on all three modes and on ite and npcx (I don't have the hw for xec).

@GTLin08 @MulinChao I've added a build check to fail the build if CONFIG_PM_DEVICE_SYSTEM_MANAGED is set but CONFIG_PM_DEVICE_RUNTIME is not. I understand that this has the annoying side effect of starting the device in suspended state, but this is just how the power management system works at this stage, there's no much I can do about it.
You think we can move on with this?

@GTLin08 @MulinChao can you take a look at this one?

@GTLin08 @MulinChao I've added a build check to fail the build if CONFIG_PM_DEVICE_SYSTEM_MANAGED is set but CONFIG_PM_DEVICE_RUNTIME is not. I understand that this has the annoying side effect of starting the device in suspended state, but this is just how the power management system works at this stage, there's no much I can do about it, at least now it stops the case where system power management messes up with the device state.
You think we can move on with this?

When CONFIG_PM_DEVICE_SYSTEM_MANAGED and CONFIG_PM_DEVICE_RUNTIME are dependent on each other, the following Kconfig setting should be modified?

@GTLin08 @MulinChao can you take a look at this one?

When both CONFIG_PM_DEVICE_SYSTEM_MANAGED and CONFIG_PM_DEVICE_RUNTIME are enabled, should we consider where to place the following function?
const struct device *dev = DEVICE_DT_GET(DT_NODELABEL(kbd));
pm_device_runtime_get(dev);

When CONFIG_PM_DEVICE_SYSTEM_MANAGED and CONFIG_PM_DEVICE_RUNTIME are dependent on each other, the following Kconfig setting should be modified?

Yeah I suppose CONFIG_PM_DEVICE_SYSTEM_MANAGED  should be enabled explicitly, the reason for that conditional default is beyond me, I'll add it to the growing list of confusing things about the PM implementation. Thanks for pointing it out.

When both CONFIG_PM_DEVICE_SYSTEM_MANAGED and CONFIG_PM_DEVICE_RUNTIME are enabled, should we consider where to place the following function?

It should be in the application on whatever code controls the keyboard. If there's no need to suspend it (for example on a always on device) it could be anywhere really, just in any SYS_INIT call.

@GTLin08 what do you think? good to go? Sorry for nudging, I need this for something downstream and the PM situation is kindof beyond this per se.


Fix buggy command paper number prefixes

This PR:

fixes the command paper number regex, which previously allowed ., which allows any character in a regex. It is now escaped (\.), therefore only a period is allowed at that point in the regex
tightens up the spacing and capitalisation validation, as many variations exist in the wild
adds support for the new CP prefix, which differs from the others as it should not have a . period after it
adds validation for suffixes (only capitalised Roman numerals are allowed)
updates the validation message accordingly
adds some hint text to the form, covering the more stringent validation checks
adds a rake task to run which fixes up the existing command paper numbers and provides detailed logs.

Trello: https://trello.com/c/yG4gXFxI/1544-fix-buggy-command-paper-number-prefixes-in-whitehall

Hi @benthorner - I've now added functionality for republishing the affected documents, as part of the rake task (see second-to-last commit). Here is a successful job (dry run) on Integration: https://deploy.integration.publishing.service.gov.uk/job/run-rake-task/130260/console
I haven't added tests for it, but it seems there's a precedent for not testing this kind of thing in rake tasks. I think the effort taken to test it would not be worth it, especially given we're deleting the code afterwards, we're recycling prior art, and I've manually tested it on Integration.
With that in mind, could you give it another look please? 😁


Error when running under phantomJS

When running under phantomJS, sightglass throw an exception at line 88 :
this.set(true, token, current, this.update.bind(this))

phantom log this message :
this.update.bind is undefined

This is because Phantom < 2 uses an old build of WebKit. Simply inject es5-shim into Phantom or include it on your page.

Can confirm that this can be resolved with es5-shim.
# Gemfile
source 'https://rails-assets.org' do
  gem 'rails-assets-es5-shim'
end

# application.js
# es5-shim must be required prior to sightglass
//= require es5-shim
//= require sightglass

Think this issue can be closed.


[wordpress] add 6.7

https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/
https://wordpress.org/news/2024/11/rollins/

Closes https://github.com/endoflife-date/endoflife.date/issues/6238


[BUG] Adding GitHub link on the project cards

Fixes #56
Changes:

@Kamalkoranga you can add a bit more consistency to the design.

aligning the GitHub link button at bottom (thus bringing them to same level)

p.s. make sure to sync your branch with main branch to avoid merge conflicts.

@Kamalkoranga the design is looking great!! You can add a bit more consistency to the design.

aligning the GitHub link button at bottom (thus bringing them to same level)

Okay... I got it

@Kamalkoranga the design is looking great!! You can add a bit more consistency to the design.

aligning the GitHub link button at bottom (thus bringing them to same level)

@AdarshRawat1  Aligned GitHub Link.

Nice work @Kamalkoranga !!

Nice work @Kamalkoranga !!

Thanks 😊


Fix expenses

Send amount of pennies, instead of rubles
Add possibility to track expenses when creating a queue
Add text formatter to expenses field


RTL does not result in straight line

The real reason is that the origin waypoint gets constantly reset. We will need to fix this for the next release.

Fis is in https://github.com/PX4/Firmware/pull/3057.

Merged.


[Suggestion] Automatic Version Increment and CFF Self-maintenance

Aeruginous v2.2.0 has two new and interesting features:  a version incrementing system as well as a CFF release date updater.  As we assemble the RONLOG with Aeruginous, anyway, I would like to suggest to also add the version incrementing feature and the CFF release date synchronisation to the RONLOG assembly workflow because I noticed that these aspects became out of sync, somehow.
Your benefit would be that would only need to activate the RONLOG assembly workflow and all hard-coded version numbers in the entire code base would be updated automatically.

Thanks for the helpful suggestion @kevinmatthes
Currently, I still prefer to manage the releases manually, since the app is changing rapidly and there are some features that related for each other (Like tags and filter, then filter and filter popup). That's why I think controlling the versioning manually could be better for the current development phase.
For that I have two suggestions:

We Add CFF release date synchronization without the auto-incrementing feature for version if that's possible.
We can implement both feature but we make their workflow starts manually if find this approach better to implement.

I'll be glade to hear your opinion about that

Thanks for the detail explanations!
I think it would be very useful to include the version incrementing feature within the workflow that assembles the CHANGELOG, since this workflow will be called before each release.
Doing that would make creating a new release just a breeze with triggering the workflow with the wanted arguments, then creating a new tag which will launch the release workflow :100:
If you think that including the CFF release date in the same workflow would be better then you can include it there too :+1:


[ERROR BUG] 'triton.language' has no attribute 'cast'. Did you mean: 'cat'?

Been using unsloth for my trainings, however updating the version resulted to an error.
Tried fine-tuning and got this error result:
2024-11-07T16:22:42.743116754Z ==((====))==  Unsloth - 2x faster free finetuning | Num GPUs = 1
2024-11-07T16:22:42.743172138Z    \\   /|    Num examples = 854 | Num Epochs = 6
2024-11-07T16:22:42.743186385Z O^O/ \_/ \    Batch size per device = 4 | Gradient Accumulation steps = 4
2024-11-07T16:22:42.743198119Z \        /    Total batch size = 16 | Total steps = 318
2024-11-07T16:22:42.743209991Z  "-____-"     Number of trainable parameters = 41,943,040
2024-11-07T16:22:44.764922932Z
  0%|          | 0/318 [00:00<?, ?it/s]Traceback (most recent call last):
2024-11-07T16:22:44.764960716Z   File "/workspace/finetune_genllm_8b.py", line 242, in <module>
2024-11-07T16:22:44.764966932Z     trainer.train()
2024-11-07T16:22:44.764973078Z   File "<string>", line 156, in train
2024-11-07T16:22:44.764979224Z   File "<string>", line 380, in _fast_inner_training_loop
2024-11-07T16:22:44.764986767Z   File "<string>", line 31, in _unsloth_training_step
2024-11-07T16:22:44.764993891Z   File "/usr/local/lib/python3.10/dist-packages/unsloth/models/_utils.py", line 970, in _unsloth_pre_compute_loss
2024-11-07T16:22:44.764999548Z     return self._old_compute_loss(model, inputs, *args, **kwargs)
2024-11-07T16:22:44.765005764Z   File "/usr/local/lib/python3.10/dist-packages/transformers/trainer.py", line 3633, in compute_loss
2024-11-07T16:22:44.765011840Z     outputs = model(**inputs)
2024-11-07T16:22:44.765017986Z   File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
2024-11-07T16:22:44.765024132Z     return self._call_impl(*args, **kwargs)
2024-11-07T16:22:44.765030348Z   File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1527, in _call_impl
2024-11-07T16:22:44.765036424Z     return forward_call(*args, **kwargs)
2024-11-07T16:22:44.765058703Z   File "/usr/local/lib/python3.10/dist-packages/accelerate/utils/operations.py", line 823, in forward
2024-11-07T16:22:44.765065268Z     return model_forward(*args, **kwargs)
2024-11-07T16:22:44.765071973Z   File "/usr/local/lib/python3.10/dist-packages/accelerate/utils/operations.py", line 811, in __call__
2024-11-07T16:22:44.765078049Z     return convert_to_fp32(self.model_forward(*args, **kwargs))
2024-11-07T16:22:44.765081890Z   File "/usr/local/lib/python3.10/dist-packages/torch/amp/autocast_mode.py", line 16, in decorate_autocast
2024-11-07T16:22:44.765086570Z     return func(*args, **kwargs)
2024-11-07T16:22:44.765091319Z   File "/usr/local/lib/python3.10/dist-packages/torch/_compile.py", line 24, in inner
2024-11-07T16:22:44.765095649Z     return torch._dynamo.disable(fn, recursive)(*args, **kwargs)
2024-11-07T16:22:44.765100328Z   File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/eval_frame.py", line 328, in _fn
2024-11-07T16:22:44.765106893Z     return fn(*args, **kwargs)
2024-11-07T16:22:44.765111712Z   File "/usr/local/lib/python3.10/dist-packages/unsloth/models/llama.py", line 1046, in PeftModelForCausalLM_fast_forward
2024-11-07T16:22:44.765117370Z     return self.base_model(
2024-11-07T16:22:44.765121630Z   File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
2024-11-07T16:22:44.765126309Z     return self._call_impl(*args, **kwargs)
2024-11-07T16:22:44.765130639Z   File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1527, in _call_impl
2024-11-07T16:22:44.765137763Z     return forward_call(*args, **kwargs)
2024-11-07T16:22:44.765142373Z   File "/usr/local/lib/python3.10/dist-packages/peft/tuners/tuners_utils.py", line 197, in forward
2024-11-07T16:22:44.765148589Z     return self.model.forward(*args, **kwargs)
2024-11-07T16:22:44.765154315Z   File "/usr/local/lib/python3.10/dist-packages/accelerate/hooks.py", line 170, in new_forward
2024-11-07T16:22:44.765159414Z     output = module._old_forward(*args, **kwargs)
2024-11-07T16:22:44.765164652Z   File "/usr/local/lib/python3.10/dist-packages/unsloth/models/llama.py", line 987, in _CausalLM_fast_forward
2024-11-07T16:22:44.765169401Z     loss = fast_cross_entropy_loss(
2024-11-07T16:22:44.765173661Z   File "/usr/local/lib/python3.10/dist-packages/torch/_compile.py", line 24, in inner
2024-11-07T16:22:44.765179388Z     return torch._dynamo.disable(fn, recursive)(*args, **kwargs)
2024-11-07T16:22:44.765185534Z   File "/usr/local/lib/python3.10/dist-packages/torch/_dynamo/eval_frame.py", line 328, in _fn
2024-11-07T16:22:44.765190703Z     return fn(*args, **kwargs)
2024-11-07T16:22:44.765195033Z   File "/usr/local/lib/python3.10/dist-packages/unsloth/kernels/cross_entropy_loss.py", line 387, in fast_cross_entropy_loss
2024-11-07T16:22:44.765201528Z     loss = Fast_CrossEntropyLoss.apply(
2024-11-07T16:22:44.765207255Z   File "/usr/local/lib/python3.10/dist-packages/torch/autograd/function.py", line 539, in apply
2024-11-07T16:22:44.765214309Z     return super().apply(*args, **kwargs)  # type: ignore[misc]
2024-11-07T16:22:44.765218569Z   File "/usr/local/lib/python3.10/dist-packages/unsloth/kernels/cross_entropy_loss.py", line 309, in forward
2024-11-07T16:22:44.765222830Z     _chunked_cross_entropy_forward[(n_rows, n_chunks,)](
2024-11-07T16:22:44.765227649Z   File "/usr/local/lib/python3.10/dist-packages/triton/runtime/autotuner.py", line 232, in run
2024-11-07T16:22:44.765232328Z     return self.fn.run(*args, **kwargs)
2024-11-07T16:22:44.765237077Z   File "<string>", line 63, in _chunked_cross_entropy_forward
2024-11-07T16:22:44.765241268Z   File "/usr/local/lib/python3.10/dist-packages/triton/compiler/compiler.py", line 430, in compile
2024-11-07T16:22:44.765246017Z     fn_cache_manager = get_cache_manager(make_hash(fn, arch, **kwargs))
2024-11-07T16:22:44.765250277Z   File "/usr/local/lib/python3.10/dist-packages/triton/compiler/compiler.py", line 253, in make_hash
2024-11-07T16:22:44.765255026Z     key = f"{fn.cache_key}-{''.join(signature.values())}-{configs_key}-{constants}-{num_warps}-{num_stages}-{debug}-{arch}"
2024-11-07T16:22:44.765259706Z   File "/usr/local/lib/python3.10/dist-packages/triton/runtime/jit.py", line 445, in cache_key
2024-11-07T16:22:44.765265921Z     dependencies_finder.visit(self.parse())
2024-11-07T16:22:44.765270671Z   File "/usr/lib/python3.10/ast.py", line 418, in visit
2024-11-07T16:22:44.765275350Z     return visitor(node)
2024-11-07T16:22:44.765281077Z   File "/usr/lib/python3.10/ast.py", line 426, in generic_visit
2024-11-07T16:22:44.765285337Z     self.visit(item)
2024-11-07T16:22:44.765290505Z   File "/usr/lib/python3.10/ast.py", line 418, in visit
2024-11-07T16:22:44.765294766Z     return visitor(node)
2024-11-07T16:22:44.765299026Z   File "/usr/lib/python3.10/ast.py", line 426, in generic_visit
2024-11-07T16:22:44.765303775Z     self.visit(item)
2024-11-07T16:22:44.765308455Z   File "/usr/lib/python3.10/ast.py", line 418, in visit
2024-11-07T16:22:44.765312785Z     return visitor(node)
2024-11-07T16:22:44.765317534Z   File "/usr/lib/python3.10/ast.py", line 428, in generic_visit
2024-11-07T16:22:44.765322213Z     self.visit(value)
2024-11-07T16:22:44.765326543Z   File "/usr/lib/python3.10/ast.py", line 418, in visit
2024-11-07T16:22:44.765331223Z     return visitor(node)
2024-11-07T16:22:44.765335483Z   File "/usr/lib/python3.10/ast.py", line 428, in generic_visit
2024-11-07T16:22:44.765339743Z     self.visit(value)
2024-11-07T16:22:44.765344004Z   File "/usr/lib/python3.10/ast.py", line 418, in visit
2024-11-07T16:22:44.765348683Z     return visitor(node)
2024-11-07T16:22:44.765353432Z   File "/usr/local/lib/python3.10/dist-packages/triton/runtime/jit.py", line 77, in visit_Call
2024-11-07T16:22:44.765358181Z     func = self.visit(node.func)
2024-11-07T16:22:44.765362442Z   File "/usr/lib/python3.10/ast.py", line 418, in visit
2024-11-07T16:22:44.765366702Z     return visitor(node)
2024-11-07T16:22:44.765371381Z   File "/usr/local/lib/python3.10/dist-packages/triton/runtime/jit.py", line 74, in visit_Attribute
2024-11-07T16:22:44.765376200Z     return getattr(lhs, node.attr)
2024-11-07T16:22:44.765380391Z AttributeError: module 'triton.language' has no attribute 'cast'. Did you mean: 'cat'?

A quick fix I used is to install unsloth from a previously working branch version:
pip --no-cache-dir install "unsloth[cu118-ampere] @ git+https://github.com/unslothai/unsloth.git@a2f8db3e7341f983af5814a2c56f54fa29ee548d"

Oh maybe this is an old triton version - I will add a flag to turn the casting off!

Even i am facing the same issue. Please help me with a resolution

Yes, getting same error
Tried the following, ended up getting more issues

.A quick fix I used is to install unsloth from a previously working branch version:
pip --no-cache-dir install "unsloth[cu118-ampere] @ git+https://github.com/unslothai/unsloth.git@a2f8db3e7341f983af5814a2c56f54fa29ee548d"

And it worked however you need to specify
os.environ["UNSLOTH_IS_PRESENT"] = "1"

which was a related issue from !1252

Same issue here

@sureshmol @arianyambao @Ar9av @jonwolds
Apologies everyone - I added a temporary solution in the nightly branch - would it possible for you guys to test to see if it works - thanks a lot - also apologies on the issue!
pip uninstall unsloth -y && pip install --upgrade --no-cache-dir --no-deps "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git@nightly"

@sureshmol @arianyambao @Ar9av @jonwolds Apologies everyone - I added a temporary solution in the nightly branch - would it possible for you guys to test to see if it works - thanks a lot - also apologies on the issue! pip uninstall unsloth -y && pip install --upgrade --no-cache-dir --no-deps "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git@nightly"

解决了 谢谢！

I am having the same issue

@sureshmol @arianyambao @Ar9av @jonwolds Apologies everyone - I added a temporary solution in the nightly branch - would it possible for you guys to test to see if it works - thanks a lot - also apologies on the issue! pip uninstall unsloth -y && pip install --upgrade --no-cache-dir --no-deps "unsloth[colab-new] @ git+https://github.com/unslothai/unsloth.git@nightly"

Hi, @danielhanchen it works by default and without the flags I explicitly set last time. However, I built it with cu118-ampere instead of colab-new:
pip --no-cache-dir install "unsloth[cu118-ampere] @ git+https://github.com/unslothai/unsloth.git@nightly"

Here's a short output:
2024-11-11T02:56:35.050957027-08:00
Map:   0%|          | 0/854 [00:00<?, ? examples/s]
Map: 100%|██████████| 854/854 [00:00<00:00, 59543.12 examples/s]
2024-11-11T02:56:35.823763879-08:00 ==((====))==  Unsloth 2024.11.5: Fast Llama patching. Transformers = 4.46.2.
2024-11-11T02:56:35.823787625-08:00    \\   /|    GPU: NVIDIA RTX A6000. Max memory: 47.536 GB. Platform = Linux.
2024-11-11T02:56:35.823794190-08:00 O^O/ \_/ \    Pytorch: 2.1.0+cu118. CUDA = 8.6. CUDA Toolkit = 11.8.
2024-11-11T02:56:35.823799358-08:00 \        /    Bfloat16 = TRUE. FA [Xformers = 0.0.22.post7+cu118. FA2 = True]
2024-11-11T02:56:35.823804177-08:00  "-____-"     Free Apache license: http://github.com/unslothai/unsloth
2024-11-11T02:56:35.823809275-08:00 Unsloth: Fast downloading is enabled - ignore downloading bars which are red colored!
2024-11-11T02:59:02.909143520-08:00 Unsloth 2024.11.5 patched 32 layers with 32 QKV layers, 32 O layers and 32 MLP layers.
2024-11-11T02:59:05.118042752-08:00
Map (num_proc=2):   0%|          | 0/854 [00:00<?, ? examples/s]
Map (num_proc=2):  50%|█████     | 427/854 [00:00<00:00, 556.73 examples/s]
Map (num_proc=2): 100%|██████████| 854/854 [00:00<00:00, 1070.49 examples/s]
Map (num_proc=2): 100%|██████████| 854/854 [00:01<00:00, 836.49 examples/s]
2024-11-11T02:59:05.209715063-08:00 Detected kernel version 5.4.0, which is below the recommended minimum of 5.5.0; this can cause the process to hang. It is recommended to upgrade the kernel to the minimum version or higher.
2024-11-11T02:59:06.223910137-08:00 ==((====))==  Unsloth - 2x faster free finetuning | Num GPUs = 1
2024-11-11T02:59:06.223946594-08:00    \\   /|    Num examples = 854 | Num Epochs = 6
2024-11-11T02:59:06.223954626-08:00 O^O/ \_/ \    Batch size per device = 4 | Gradient Accumulation steps = 4
2024-11-11T02:59:06.223959305-08:00 \        /    Total batch size = 16 | Total steps = 318
2024-11-11T02:59:06.223962727-08:00  "-____-"     Number of trainable parameters = 41,943,040
2024-11-11T02:59:11.991167966-08:00
  0%|          | 0/318 [00:00<?, ?it/s]
  0%|          | 1/318 [00:05<27:22,  5.18s/it]

Thank you!

@arianyambao Oh ok glad it works!
@opertifelipe Did you try updating Unsloth? pip install --upgrade --no-cache-dir --no-deps unsloth

@arianyambao Oh ok glad it works!
@opertifelipe Did you try updating Unsloth? pip install --upgrade --no-cache-dir --no-deps unsloth

Yes, now it works! 😀


Memory leak

Suspect the text component leaks memory whenever recreating the texture.

Fixed; turned out the switch-case statements in the the Image class didn't have any breaks!


No readme on npm

Hello there,
I know that you guys are working on the 3.0 release, but I'm a little confused which set of documentation I'm supposed to be looking at.
https://www.npmjs.com/package/redux-loop has no README right now and the neither the examples in the  examples directory nor the example inline in the README of the master branch seem to work. What's the recommended way to install / use redux loop?

I'll definitely update this. Thanks!

3.0 is released and has a readme. Thanks again!


Update images and remove unused images

Deleted expiring images that currently are not used on any pages

closing this one, as started a fresh pull request


[Wait for #1584] [Test] Add bn layer inference test

[Pending commit: #1584]
Commits to be reviewed in this PR
[Test] Add bn layer inference test
Changes proposed in this PR:

bn layer inference mode test
add option to skip backwarding golden test

Self evaluation:

Build test: [X]Passed [ ]Failed [ ]Skipped
Run test: [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: Jihoon Lee<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #1587. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnstreamer.mooo.com/.


Sass version?

Any chance of a sass version of this?

It shouldn't take too long to convert to sass, but currently we have no plans of shipping an official port. We're open to contributions though! :)


User Styles not loading with shadow DOM

After the last release of yesterday, my stylesheet (that was working before) is not loading anymore.

If you disable the shadow DOM in the settings and reload the editor, does it work again?
Can you paste in your stylesheet?

Hi, disabling the shadow dom and restarting atom fixes the issue! thanks!
Here is my stylesheet, anyway:
atom-text-editor .selection .region {
  background-color:#333;
}

atom-text-editor .invisible-character {
  color:#555;
}

.editor.is-focused .selection .region {
  background-color:#333;
}

.editor {
  background:#111;
}

.tree-view {

}

atom-text-editor {

}

atom-text-editor .cursor {

}

You need to update your sheet for the shadow DOM change. You should be able to get away with changing it to this:
atom-text-editor::shadow .selection .region {
  background-color:#333;
}

atom-text-editor::shadow .invisible-character {
  color:#555;
}

atom-text-editor.is-focused::shadow .selection .region {
  background-color:#333;
}

.editor {
  background:#111;
}

Check out this document: https://atom.io/docs/latest/upgrading/upgrading-your-ui-theme

@nathansobo are we autoconverting the user's sheet? Can we? Or can we detect that they have improper styles and pop up a notification when the shadow DOM is enabled?

Great, it worked! Sorry for not being able to find that document by myself!

No prob, we should be better about notifying you that you need to make changes.

@benogle We could scan for .editor and atom-text-editor selectors that have descendants without a ::shadow and warn...

That would be nice. Then I can write up a doc specific to the user sheet (basically trimmed down version of that doc above), and we can link to it in the doc. I think a notification rather than dep cop would be the best thing for the user sheet as the user can fix it.

Thanks for pointing in the right direction. FWIW this issues page was the first place I looked. A notification would be great!

The default stylesheet should be updated. I don't believe the atom-text-editor .cursor {} rule will work.
Eg:
/*
 * Your Stylesheet
 *
 * This stylesheet is loaded when Atom starts up and is reloaded automatically
 * when it is changed.
 *
 * If you are unfamiliar with LESS, you can read more about it here:
 * http://www.lesscss.org
 */

.tree-view {

}

atom-text-editor {

}

/*
 * The editor itself uses a shadow DOM so rules must start with
 * atom-text-editor::shadow or they will be ignored.
 */
atom-text-editor::shadow {
  .cursor {

  }
}

@Zren Thanks for pointing that out. Updated via ab4588571dcbba05dbd15d3257bebdd0cce3d2d3.

Closing in favor of https://github.com/atom/atom/issues/5149 for a message.


undefined method `ad_hoc_option_values'

I'm having trouble with this gem.  I have it working in my development environment but when I push it to the server I get this error whenever I try to view / edit an order.
[2019-04-09T16:48:39.640103 #5915] FATAL -- : [63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1] ActionView::Template::Error (undefined method `ad_hoc_option_values' for #<Spree::ShippingManifest::ManifestItem:0x0000563a415f1168>):
F, [2019-04-09T16:48:39.640353 #5915] FATAL -- : [63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1]     1:

[63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1]     2:   <%# TODO: group multi-select options (e.g. toppings) %>
[63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1]     3:

[63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1]     4:     <% item.ad_hoc_option_values.each do |ad_hoc_option_value| %>
[63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1]     5:
<%= ad_hoc_option_value.option_value.option_type.presentation %>: <%= ad_hoc_option_value.option_value.presentation %>

[63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1]     6:     <% end %>
[63f9bd8d-3d90-4b9b-8b6b-2aaa6bfacec1]     7:     <% item.product_customizations.each do |customization| %>

@hkrdrm  what environment is your server set to?   @acreilly  can you take a look?

its set to production I ran the rake task with RAILS_ENV=production also.  It seems like it might have something to do with a particular order or maybe the way the product is setup.  I can get the error also in the dev environment now if choose an older item but the new item i setup doesn't cause the error.

I think I've narrowed the problem down before you click ship Spree:LineItem is being passed into the _additional_line_item_fields.html.erb partial.  But once you click ship it then tries to pass in Spree::ShippingManifest::ManifestItem but its looking for LineItem not ShippingManifest.
I may try to hack it a bit it looks like the ShippingManifest has LineItem as a child.

<% if item.is_a?(Spree::ShippingManifest::ManifestItem) %>   <% item = item.line_item %> <% end %>
Adding these 3 lines to the top of _additional_line_item_fields.html.erb seems to have solved the problem.  Not sure if this is a proper fix though.


fixed remote-sr chrome profile not parsed on windows

path in windows format does not match linux style path
Pull request status:

[x] Code conventions
[x] Ready for review

Works fine on my Laptop (macOS) 👍


Jupyter audio cues stop working

Does this issue occur when all extensions are disabled?: Yes
Disabled all extensions then enabled Python extension which enabled a few others

VSCode info
Version: 1.74.2 (system setup)
Commit: e8a3071ea4344d9d48ef8a4df2c097372b0c5161
Date: 2022-12-20T10:29:14.590Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19044
Sandboxed: No
Steps to Reproduce:

Open settings.json, use values

    "audioCues.notebookCellCompleted": "on",
    "audioCues.notebookCellFailed": "on",

Git clone https://github.com/Curt-Park/rainbow-is-all-you-need/blob/master/04.dueling.ipynb
Open the 04.dueling.ipynb notebook
Run the cells up to and including the Initialize header, the audio cue should play
Run the cell containing agent.train
Minutes later the cell completes, audio cue doesn't play
All cells no longer play happy audio cues ): even in other notebooks
Run a cell with assert False and the sad audio cue still works
Reload window and the success cues work again until they stop again for some reason

Is it always that cell with agent.train that breaks it? Are you doing anything else while it's running? (working in other notebooks, making edits in this notebook, etc)

There's a lot that seems to not be working upon further inspection
Here's a video, make sure to turn the volume on. The extensions are what gets enabled when I enable python after disabling everything.
https://user-images.githubusercontent.com/9356891/211127264-441819c6-32cd-4f14-bae1-cba9204a20ba.mp4
A few things I noticed

Sounds didn't work at the start before agent.train was called
Sound doesn't play consitently when running the same cell over again
Sound breaks after running train with 1000 but not 100 or 10
Sounds for errors dont break but they also have consistency issues
Right now the sound is only played once when running multiple cells

I can repro this. I sometimes get this error

then the sound won't play anymore. Need to remove the sound from this.playingSounds when it fails to play

It doesn't happen reliably though. I'm not sure why I got this error.

And when I set a breakpoint in playSound then it seems to happen every time.

Need to remove the sound from this.playingSounds when it fails to play

This is fixed now. Does this bug still reproduce?

Marking as verified by author.


Enable filter on data.format

Issue
#304
Short description
Add dataformat to the filter options, so that filtering is possible on data.format.
This may work as a mitigation for https://github.com/equinor/fmu-dataio/pull/492. However, note:

Require data consumers to actively filter on supported formats ⚠

An alternative would be to default to data.format="irap_binary" in the explorer, but this does not feel right.
Extra: Also improved testing of some other filters (assert that no results come back when filtering on non-existing value)
Pre-review checklist

[x] Read through all changes. No redundant print() statements, commented-out code, or other remnants from the development. 👀
[x] Make sure tests pass after every commit. ✅
[X] New/refactored code is following same conventions as the rest of the code base. 🧬
[x] New/refactored code is tested. ⚙
[x] Documentation has been updated 🧾

Pre-merge checklist

[ ] Commit history is consistent and clean. 👌

Don't know if this is the best way of solving this, inputs appreciated 💬

For some reason I missed that the .format method was already there on the Child object. I will have another look at this to make sure things are consistent.


Docker update not considering date

It looks like for latest we are just comparing the strings semantically and not considering the order in which they are added? https://github.com/autamus/cuppa/blob/0911790f92cef38d9fe19e724b93d8a09dc47e48/providers/docker/containers.go#L50-L65
This is leading to bugs in shpc where container tags are "updated" with older versions, see https://github.com/singularityhub/singularity-hpc/pull/500#issuecomment-1056324758
cc @marcodelapierre

Hey! So we actually do consider the published date of a container. The code that you linked is responsible for filtering out containers that don't match a filter if provided. I think the code you're looking for is, https://github.com/autamus/cuppa/blob/0911790f92cef38d9fe19e724b93d8a09dc47e48/results/resultset.go#L91-L103

Gotcha! And I think we've discussed this in slack and know the particular issue.


Replace Monkeypatching of BasicObject with TracePoint

Here's a first stab at this work.
I have broken a LOT of tests, which need fixing.
That said -- query generation definitely works! 🎉

Here's a first stab at this work.
I have broken a LOT of tests, which need fixing.
That said -- query generation definitely works! 🎉

So I tried to get this back to green.
A few things to note. I've added TODOs where there are definitely things to fix.
I've tried to get the CallStack re-implemented using TracePoint return and raise.
I like a lot of the removal of complexity. Unfortunately some of the complexity is necessary.
I didn't manage to get fully explanatory specs around exactly what some of this stuff has been added for. And some of it is just stabbing-in-the-dark until we get bundler and rails to green.
Anyway. You'd removed the explicit setting of the class_method boolean. I don't think we can get around this. We have to determine whether it is a class method based on who self is, and not based on whether or not that method is present as an instance_method.
I think that rather than have two things: a call_site and a called_code concept, we'll need more.
We have to record the

Container method containing the call_site and it's source location (file and line number), class and whether or not it is a class method.
The call_site information - file and line number
Method being called at the call_site, source location, class, and whether or not it is a class method.

I'd shovelled in the containing method information into the call_site information and had to hack on the method_definition_line stuff etc.
So I think you are correct to remove it from there.
However, we still want the info.
I think it will be easier to just deal with the three things, than forcing call_site to also record information about its container method.
Hope this makes sense.

I suspect that we might also not be covering this case correctly:
#a.rb
class A
  def super_class_method #called_code
     C.something_else
  end
end

#b.rb
class B < A
end

#c.rb
class C
  def self.something_else
  end
end

#bin/script
B.new.super_class_method #call site

container_method should look like
{object: "(main)", method_name: "(main)", line_number:0, file: "bin/script", class_method: false}

call_site should be
{object: B, method_name: "super_class_method", line_number: 1, file: "bin/script"}

called_code should be
{object: B, method_name: "super_class_method", class_method: false, line_number: 2, file: "a.rb"}

Also I think it is clear that call_site is a different type of CodeLocation to container_method and called_code

This is a nice to have but perhaps ideally call_site would include the character where the method is called.
product.name || Lookup.default_name
{line_number: 15, file: "search.rb", character: 8}

{line_number: 15, file: "search.rb", character: 22}

@muzfuz - I pushed quite a few changes. It's not quite green yet. Just integration specs left.
I'm not sure what the issue is yet.
Looks like the CallStack.pop gets called too many times during the return TracePoint.
Perhaps it is too permissive in comparison to the call TracePoint so manages to execute more times than the CallStack.push

Thanks for all these changes @markburns -- have gotten sidetracked by other issues this morning, but will try to get back on later this afternoon.

No worries. And thanks for working on it too!
I think it's close to being fixed. I feel like it should be something simple.
We should maybe add a few more unit specs to get to the bottom of it. I've done a lot of moving things around and things are probably being tested at the wrong level now.
 I started building a very similar tool using TracePoint as well just a week ago. Seems you're much further along with me so will start contributing to here 👍

Looks like the latest changes have caused my local test app to stop logging out events.  Taking a look at why that is.

Happy to have more input @chrisface !

Hey guys. Sorry it's late here. I may have left it in a messier state than it was before with the TracePoint stuff.
If you need to roll back a bit that's fine. Hopefully it's reasonably obvious what I was going for.
It's quite hard to debug because RSpec just exits if there's anything goes wrong inside the TracePoint code. And byebug doesn't work either.

Yeah I find a combination of running specs and running a small test ruby app works quite well.
I think the code is overall in a better state, and I suspect the reason for things not getting logged out it quite straightforward.  Will hopefully solve soon.

Right, I commented out on_return.enable on this line here, and method logging has started working again.
https://github.com/ruby-analysis/delfos/blob/use_tracepoint/lib/delfos/method_trace.rb#L15
Will try to figure out why now.

@bestie - we just started hacking on the TracePoint idea.
Did you get anywhere with it yourself?

@muzfuz - yeah that makes sense that it started working again.
The only issue is that it breaks CallStack recording.
I.e. the chains of execution.

Indeed, seeing that now.  Hm...

Hey @markburns could you please clarify why you want to temporarily disable TracePoint?  I'm actually not sure I understand why we need to flip it off / on

I think here's the approach I'll take on this.
trace.enabled?
#=> true

trace.disable do
    trace.enabled?
    # only disabled for this block
end

trace.enabled?
#=> true

Hey @muzfuz -
I think we don't need it.
Sorry that's a red herring. In writing my explanation, I wrote this snippet to show the thinking. However the output shows that the individual TracePoint is disabled inside TracePoint blocks.
E.g.
def outer
  puts "outer: before inner"
  inner
  puts "outer: after inner"
end

def inner
  puts "inner"
end

def internal_trace_point_method
  puts "TP: don't trigger trace point in here"
  another_tp_method
end

def another_tp_method
  puts "TP: don't trigger trace point in here"
end

TracePoint.new(:call) do |tp|
  puts "TP: call #{tp.method_id}"
  internal_trace_point_method
end.enable

TracePoint.new(:return) do |tp|
  puts "TP: return from #{tp.method_id}"
end.enable

outer

We see
TP: call outer
TP: don't trigger trace point in here
TP: don't trigger trace point in here
outer: before inner
TP: call inner
TP: don't trigger trace point in here
TP: don't trigger trace point in here
inner
TP: return from inner
outer: after inner
TP: return from outer

I think it's possible you're correct but any assumptions you're making
based on using pry etc may be way off.
Using pry to look at this may give you a distorted view
On Fri, 9 Jun 2017 at 22:40, Mazin Power<EMAIL_ADDRESS>wrote:

@muzfuz commented on this pull request.
In lib/delfos/method_trace.rb
https://github.com/ruby-analysis/delfos/pull/13#discussion_r121128068:

 end

 def handle_return(tp)

   temporarily_disable_trace_point do

     call_site = call_site_from(tp)

     return unless relevant?(call_site)

     CallStack.pop rescue nil

   end

 end

 private

 def relevant?(call_site)

   AppDirectories.include_files?(

     call_site.path,

Right so looking closely at this - I think we do need this, but before we
reach this step we will want to do some blanket filtering based on
tracepoint file path.
We will want to go and do this stuff for our call_site, but before we
get to that point we should also check that we are in the right file by
using tp.path -- otherwise we get bindings into all sorts of places like
main and Irb or Pry.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ruby-analysis/delfos/pull/13#discussion_r121128068,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGW3svjkwmX5M1DjPdQKWpJC7EPlYcmks5sCUsygaJpZM4Ny9yK
.

Not using pry :) I'm running specs and simultaneously executing this small program on the side, which is helping to bubble up these issues.
In this case, executing DelfosTest.exec in the context of main breaks (it so happens that I have Pry set up as my console, but this also happens in Irb).
require "logger"
logger = Logger.new(STDOUT)
require "delfos"
Delfos.setup!(logger: logger)

class Product
  def initialize(price = nil, name = nil)
    @price = price
    @name = name
  end

  def change_name(name)
    @name = name
  end
end

class DelfosTest
  class << self
    def exec
      product = Product.new
      product.change_name("Car")
    end
  end
end

DelfosTest.exec

Nice.
I think your logger setup should be unnecessary and if not we should work
to make this default.
Also let's make a simple program like this a default that is available in
the examples directory.
Based on how simple your program is and how little time I spent on trying
to fix the build yesterday I think you'd more productively spend your time
fixing stuff
I've just spent a portion of my day trying to improve things but may have
made stuff worse.
Sorry if this feedback is not super useful!
On Fri, 9 Jun 2017 at 23:16, Mazin Power<EMAIL_ADDRESS>wrote:

Not using pry :) I'm running specs and simultaneously executing this small
program on the side, which is helping to bubble up these issues.
In this case, executing DelfosTest.exec in the context of main breaks (it
so happens that I have Pry set up as my console, but this also happens in
Irb).
require "logger"
logger = Logger.new(STDOUT)
require "delfos"
Delfos.setup!(logger: logger)
class Product
def initialize(price = nil, name = nil)
@price = price
@name = name
end
def change_name(name)
@name = name
end
end
class DelfosTest
class << self
def exec
product = Product.new
product.change_name("Car")
end
end
end
DelfosTest.exec
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ruby-analysis/delfos/pull/13#issuecomment-307400937,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGW3pKBsjqNSGNGMTPB43u6jGtDwtNfks5sCVO5gaJpZM4Ny9yK
.

I found the logger step necessary, but yes I agree we should make it default.
I agree it might be a good idea to include this program as a test step -- I'll look at doing that soon.
I've also been making changes this end which I think has made everything work correctly.  Just running a few more tests and then will push it up -- happy to do another branch if it'll help avoid confusion.

Right so it's a fairly small refactor, but I think it's cleaned things up a bit, and it looks like events are now firing correctly.
My next step is to look at the red specs, add a few integration cases, and also look at handling the raise events.

@muzfuz - this is back to green now. Before merging I want to tidy up the history and add in some specs for the MethodTrace stuff. Also break apart into smaller classes.
So the code that sets up and disables TracePoint will be separated from the code that builds the container_method, call_site and called_method.
Calling it a day here on this. So if you happen to be looking at it this weekend, then feel free to give it a shot.
In fact I'm less bothered about the breaking into smaller classes than tidying up the history and adding specs. So would merge with just those changes

Liking these changes @markburns
I'll get started on cleaning up the commit history and then think about writing a spec for MethodTrace.
I agree it may be worth merging now and then iterating, to avoid having this pull request balloon into an even bigger set of changes.

@markburns unfortunately not, I was thinking about it but didn't have chance to dig in. This sounds great though, looking forward to making use of it!

@markburns Right I have cleaned up the commit history.  If you disagree with these then feel free to overwrite with your local branch.
I'll now look to add a unit test for MethodTrace.  Need to think about testing strategy on this one, as obviously we don't really want to test TracePoint itself.

Yeah I'd just test that something gets called when you enable TracePoint
then beyond that method call test in an isolated class or classes
completely decoupled from TracePoint. The only difficulty might be the
stack offset which we will probably need to make overridable
On Sun, 11 Jun 2017 at 05:05, Mazin Power<EMAIL_ADDRESS>wrote:

@markburns https://github.com/markburns Right I have cleaned up the
commit history. If you disagree with these then feel free to overwrite with
your local branch.
I'll now look to add a unit test for MethodTrace. Need to think about
testing strategy on this one, as obviously we don't really want to test
TracePoint itself.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ruby-analysis/delfos/pull/13#issuecomment-307587268,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGW3h_QcCp_Jawip2mPbpZZ1OGa2DTsks5sCvbtgaJpZM4Ny9yK
.

I've done the decoupling work and all the unit tests are passing. Although integration specs aren't.
I want to replicate the higher level failures with lower level failing unit tests and hopefully fix both sets in one.
Probably calling it a day here now. But will probably have a look in the morning tomorrow too.

If you get to look at this before me. A tip (apologies if it's obvious), is to debug during a spec before a failure, then paste the query into to the neo4j http://localhost:7476/browser query editor.
Then delete sections of the query until you find which part isn't present.
It seems that currently the call sites call their own container methods:
/spec/integration/neo4j/call_sites_spec.rb:48

 MATCH (b:Class{name: "B"})  -  [:OWNS]
          ->  (mb:Method{type: "InstanceMethod", name: "another_method"})

          -[:CONTAINS]->(csB2C:CallSite)-[:CALLS]->(mc)
        MATCH (a:Class{name: "A"})  -  [:OWNS]
          -> (ma:Method{name: "some_method"}) -[:CONTAINS]->cs

        RETURN a,ma,mb,mc, cs

@muzfuz - still not much closer to fixing the integration specs.
Unfortunately since using TracePoint this library has gotten much harder to debug/work with. As pry or byebug no longer work.
The remaining failures are possibly just to do with the stack offset values.
I'd like to get a good way of testing them, but binding_of_caller only works on the current binding. E.g. you can't pass a binding around and get its first caller.
You just get the first caller of the current call site.
E.g.
require "binding_of_caller"

def i_want_this_binding
  message = "should be this"
  called_method()
end

def called_method
  binding
end

def but_i_get_this
  message = "unexpected"
  other_call_site
end

def other_call_site
  puts i_want_this_binding.of_caller(1).eval "message"
end

but_i_get_this

Expect "should be this" but get "unexpected"

@markburns we are taking a look this morning, going to try to pair up with someone this end to get it over the line.

Right so I think I know what's going on with custom_logger_spec
We are setting up with application_directories: ["fixtures"], but then we actually execute in the context of the spec file by using loading_code.
This means that we don't actually do any method tracing for our execution context.  That's the first problem.
If move you the loading_code to a.rb then the test passes, BUT only if you execute A.new.some_method.  If you subsequently also execute B.new.another_method anything then it thinks that call_sites.length is 7.
This is because we in fact have multiple call_sites arrays.  So interesting behaviour that I wouldn't have expected, but it actually seems to make sense.
You can see this behaviour in the commit I just pushed up.
Try running this spec and then uncommenting line 27 in a.rb.

Right I've actually added a test runner and that's sorted it out.  Execution context was obviously the issue there.  Take a look at 7059ecd to see the thinking from earlier.

Looking at the rest of these tests -- we might be better off reworking these to run against the actual test code, and then ensuring that we are sending the correct objects to our logger.

Sure. These tests were mostly added for edge cases and when used with the
tons of meta programming approach.
It probably does make sense to make the boundary point the neo4j logger and
also add more unit tests for the query generation at the other side of that
boundary point.
On Tue, 13 Jun 2017 at 00:58, Mazin Power<EMAIL_ADDRESS>wrote:

Looking at the rest of these tests -- we might be better off reworking
these to run against the actual test code, and then ensuring that we are
sending the correct objects to our logger.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ruby-analysis/delfos/pull/13#issuecomment-307834036,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGW3tcPaZzPo0zyJCmqxvOjPyWq5IKNks5sDWASgaJpZM4Ny9yK
.

💯