RFC: Improved Semantic Highlighting

Improved Semantic Highlighting RFC
The current semantic highlighting doesn't do much:

"Properties" x.y are just based a syntactic rule (line 443).
We look up the TermInfo node in the InfoTree and check whether identifiers are variables, which get the variable semantic token type.
Highlight tactics as keywords.

And that's about it.
But Lean is uniquely equipped to do some amazing semantic highlighting,
as all the information is already in the InfoTree, and you can go into MetaM using the same
context that terms have been elaborated with.
After a bit of playing around, I have arrived at this (very unpolished) proof of concept,
just to give an idea of what is possible:

I had already created a thread on Zulip,
and while it got lots of positive reactions, I didn't get a clear answer on how to proceed,
so I hope I'm not doing anything wrong by opening an RFC.
The contribution guide says an RFC is required before a PR.
This would be my first contribution to Lean itself.
Considerations
Which tokens should get which token type and which token modifiers?
Which of the following features should be implemented or not, and which are the priorities?
Four Major Kinds of Tokens
I am not sure which kinds of tokens are the most useful from a UX perspective to distinguish,
but so far I have settled on a distinction between types and propositions, and then values vs proofs.
This results in four major token kinds, which are determined using Meta.inferType twice:

expr : ... -> Type _         are types (.type token modifier).
expr : ... -> Prop           are predicates (.prop).
expr : ...            : Type are values (.value).
expr : ...            : Prop are theorems (.proof).

Namespaces and Dot Notation
Currently, Lean.Expr gets highlighted as one token.
I think it would be better if Lean. was highlighted as a namespace, and Expr as type.
If the "namespace" is actually a type, for example in Person.name,
then Person should get highlighted as a type, and .name as the function.

I think that given p : Person, p.name should have name highlighted as a field, not a function.
But Person.name should be highlighted as a (projection) function, which it is.
Implementing this would be non-trivial, probably requiring a fold over the x1, x2, ..., xn in x1.x2. ... .xn.
It's probably not worth the effort, but would be cool.
We often write myList.length. In this case, should .length be highlighted as a function, since List.length : List α -> Nat, or as a non-function, since List.length xs : Nat?
I think the latter makes more sense, but would be (much) harder to implement.
Tactics
How should tactics get highlighted?
Punctuation
So far only identifiers get highlighted, but Lean is quite notation-heavy.
How should the ∀ and , in ∀x, 1 = 1 get highlighted?
What about ->, =>, etc?
What about the . in (. + 2) vs the . in (Vec . 3)?
Custom Notation and User Extensibility
Existing notation for some types such as =, ∀, ∃, × etc.
do not get highlighted at all currently.
I would expect them to get highlighted the same color as Eq, Prod, etc.
I suppose it would be possible to simply hardcode sufficiently many special cases, but that feels wrong.
I think it could be useful to be able to highlight tokens based on nearly
arbitrary (user-defineable?) rules.
This would address the custom notation problem, as well as allow the following:
For example, while working on a proof about real numbers, it might be useful to highlight
variables x for which x < 0 exists in the context.
Or perhaps a type A occurs frequently in our theory and means something important,
and we want to highlight that, for example highlighting all tasks x : Task Nat.
I imagine this would come in handy when screenshotting code for a presentation or giving a demo,
where you want to highlight certain things.
I have not done any work on this front, and the extra complexity might not be worth it, or at least not currently.
How to handle abbrev?
What should abbrev Vec3f : Type := Vec Nat 3 be highlighted as?
I would say the same color as Vec, but without the .func modifier.
What should abbrev Vec3 (α : Type) : Type := Vec α 3 be highlighted as?
What should abbrev Vec3 {α : Type} : Type := Vec α 3 be highlighted as?
Universes?
Currently Type and 0 in Type 0 get highlighted differently.
I think it would make sense to highlight both and max, imax with the same token kind.
Numbers, Strings
It might be possible, due to OfNat or coercion or notation, to have 0 refer to a function or a type instead of the value.
In that case, 0 should get highlighted accordingly.
Strings currently are only syntactically highlighted using textmate scopes,
which causes the . in s!"hello {user.name}" to be highlighted as a string.
Semantic token highlight has higher priority than textmate scopes, so we would probably need to
make sure that every character inside {..} gets a semantic token.
I have zero experience with textmate scopes, so I'm not sure if it can be fixed there.
Fork Default VSCode Theme?
The experience with existing themes should be "good enough",
re-using existing LSP token types and modifiers.
However, Lean is just different enough that we quickly hit limits.
There will be new token types and new token modifiers.
I think the ideal solution is to offer a fork of the VSCode Dark+ and the VSCode Light+ themes
and fine-tune them for Lean.
This way, when e.g. giving a tutorial on Lean, you can point new users to the theme, which is a simple one-click install, and which can serve as a starting point for users wishing to customize it.
Alternatively, it would be rather easy to create a small token customization generator where users can just tweak some few base colors to make it fit into their existing theme.
The Implementation so far
So far, the declaration kind (whether it's a definition, constructor, inductive type, theorem, recursor, etc.)
determines the token type, and its role (whether it's a type, predicate, proof, value, etc.) determines the token modifiers.
If we want to re-use existing token types and modifiers as much as possible, it might make sense to introduce a simple internal-only token kinds (?) enum, and then let tokens have a set of these token kinds, which then get mapped to LSP token types and LSP token modifiers.
Just for the sake of code cleanliness, as I've found it be a little awkward having to decide whether something is a token type (there can be only one per token!) or a token modifier.
Handling of auxDecls
When we encounter an fvar that is an auxDecl, we check the Environment (of the next command)
for a constant named currentNamespace ++ fvar.userName. This feels very hacky, I wonder whether there's a better way available.
How LSP Semantic Tokens work
The LSP allows text ranges to have exactly one token type, and any amount of token modifiers,
written tokentype.mod₁.mod₂.mod₃, which can be easily customized in your VSCode settings.json.
Token modifiers are encoded as a bit-field, which presumably implicitly imposes some limit (32 modifiers? 64?).
For example, variable.declaration.proof.
It is possible and easy to introduce new token types and modifiers,
no need to touch the VSCode extension.
Just in case some readers don't know.
TODOs

[ ] Highlighting tactics. Maybe some tactics should have a different color than others?
[ ] Re-use existing LSP token types and modifiers.
[ ] Create Lean-tuned fork of VSCode Dark+ and Light+ themes.
[ ] Functions defined via where seem to break currently.
[ ] Add some option modifier to name in set_option name. Similar for import X, open X.

(This is awesome to discuss as far as I'm personally concerned, thanks for pushing it forward)
Will throw in an additional consideration which probably seems related -- perhaps some semantic highlighting of the checkpoint tactic is useful? There's this old Zulip thread that I was keeping an eye on with a comment from Leo saying:

In the future, it would be great to have UI support to mark the part we are working on.

Perhaps signaling such a thing as part of the semantic highlighting (by e.g. differentiating between tactics which are above the checkpoint) is also something worth thinking about.
To throw out another brainstorming idea, perhaps some Lean API that allows someone writing a tactic (or some other more general piece of syntax) a way of tweaking how it will be semantically highlighted will be useful as well.

Hey Max, just wanted to say we're aware of the RFC and appreciate your work! I believe we definitely want to land some version of this. Right now we're not actively working on the LSP and don't have the bandwidth to make design decisions on all those important points you mentioned above, but I hope we will be able to get back to this soon.

I'm happy about the positive reception! I understand there is limited capacity, and am a little busy recently as well. But I am happy to work on this (and potentially other Lean tooling) eventually :).
I think the biggest decision to be made here is whether we want highlighting to be user-extensible. If yes, then all the above considerations just become a matter of converging to some sensible defaults. I refer to this Zulip comment to further highlight (pun intended) the usefulness of user-extensible highlight rules. And I haven't looked into highlighting in the infoview at all yet.
Admittedly I do not fully understand Julian's remarks, as I haven't used checkpoint before.

In the future, it would be great to have UI support to mark the part we are working on.

I mean, the UI already exists - that's what the margin bar is for.

But I am happy to work on this (and potentially other Lean tooling) eventually :).

Awesome!

I think the biggest decision to be made here is whether we want highlighting to be user-extensible. If yes, then all the above considerations just become a matter of converging to some sensible defaults.

Yes, I consider this RFC to be about the default style. Extensibility is good but could come later.


Curl is not working

Curl in PHP 5.6 in my macbook air m1 is not working can anyone please guide me how I can fix it.

@vasim-seta Please run brew update and reinstall<EMAIL_ADDRESS>brew update
brew reinstall<EMAIL_ADDRESS>
Let me know if you still get the error. Please provide logs in that case.


Adds remove functionality

Description
Added remove method to heap and scheduler.
#2
Checklist

[x] added unit tests
[x] run the examples

make sure to remove the commit that changed the package-lock.json


Upload 2024-2.0 tiled envs to Zenodo

Artifacts from:

https://github.com/nsls2-conda-envs/nsls2-collection-tiled/pull/29

https://github.com/nsls2-conda-envs/nsls2-collection-tiled/actions/runs/8973247394

Deposited to https://zenodo.org/records/11122851.


Promise do not change to "resolve" mode when calling the function again.

I call to "roy" function and then i call again to the same function,
but in the second time i call to my resolve, but resolve it not back and instead it stuck on "pending" state.
roy = (num=0)=>{
return new Promise((resolve,reject)=>{
if(!num)
	roy(num+1);
else
resolve(55);

})
}
roy().then(x=>{
console.log('x:',x);
})

Console:
Promise {[[PromiseStatus]]: "pending", [[PromiseValue]]: undefined}
proto
:
Promise
[[PromiseStatus]]
:
"pending"
[[PromiseValue]]
:
undefined

It works as expected. Every call of roy() gives a new instance of a Promise. So on the first call it returns a new Promise that will never be resolved because condition will never call else statement. num is a local variable. It is not persisted anywhere and destroyed after roy() is called. A Promise will be resolved only in case when you pass a positive number to roy(number). There is defiantly an issue in the logic.
 If you want this to be resolved
roy().then(x=>{
   console.log('x:',x);
})

then remove this
if(!num)
   roy(num+1);
else

Hi @constgen,
I just give an example for load more items.
Lets say example for load more likes of instagram post, till you get end.
So in this case you will need to call again to same function but with another next_token.
The problem, when you will finish iterate all likes and then go out to your resolve you will find yourself stuck in pending mode.
What i am trying to figure out, how can i go to .then function, when i need to call again to the same function.
Hopefully i succeed to explain myself better.

For those who have also problem like me,
i solved the problem with using create new function with name: "loadMore", inside the promise.
In the "loadMore" i call again the request i need.

Any way it was not an issue of promises themselves. It is recommended to ask such questions in forums, Slack channels, etc.


[DE DateTimeV2] The time expressions like "anderthalb", "einundhalb", und "zweieinhalb" are not recognized.

Describe the bug
The time expressions like "anderthalb", "einundhalb", und "zweieinhalb" are not recognized in LUIS.
To Reproduce
Steps to reproduce the behavior:

Go to LUIS
Type 'Spule anderthalb Stunden vor '
See error

Expected behavior
The recognized times should be:

anderthalb Stunden = one and a half Hours (= 90 Minutes)
zweieinhalb Stunden = two and a half hours

Sample input/output
In the following examples,

Spule anderthalb Stunden vor
Spring zweieinhalb Stunden nach vorne

The recognized times should be as mentioned:

anderthalb Stunden = one and a half Hours (= 90 Minutes)
zweieinhalb Stunden = two and a half hours

Platform (please complete the following information):

Platform: .NET
Environment: LUIS
Version of package: the last version

Additional context
Add any other context about the problem here.

@LionbridgeCSII, can you take a look? Thanks.


Data Platform OMAS - TabularSchemas not created for DeployedDatabaseSchema

Using the Data Platform OMAS Java Client, a list of TabularSchemas is provided when creating a DeployedDatabaseSchema. The request is accepted by the OMAG server and the DeployedDatabaseSchema is successfully created.
Searching for the DeployedDatabaseSchema asset afterwards returns no associated TabularSchemas. Searching for TabularSchema/TabularColumn entities returns no results. Tests below performed using Swagger.
POST /servers/{serverName}/open-metadata/access-services/data-platform/users/{userId}/deployed-database-schema
{
  "externalSourceName": "test-dataPlatform",
  "deployedDatabaseSchema": {
    "qualifiedName": "test-DeployedDatabaseSchema",
    "name": "test-DeployedDatabaseSchema",
    "displayName": "test-DeployedDatabaseSchema",
    "tabularSchemaList": [
      {
        "qualifiedName": "TabSchema",
        "name": "TabSchema",
        "displayName": "TabSchema",
        "tabularColumns": [
          {
            "qualifiedName": "TabCol1",
            "name": "TabCol1",
            "type": "INTEGER"
          },
          {
            "qualifiedName": "TabCol2",
            "name": "TabCol2",
            "type": "STRING"
          },
          {
            "qualifiedName": "TabCol3",
            "name": "TabCol3",
            "type": "STRING"
          }
        ]
      }
    ]
  }
}

RESPONSE:
{
  "class": "GUIDResponse",
  "relatedHTTPCode": 200,
  "guid": "165ff2a0-f5b6-48cf-92bd-f7a40a54a3ba"
}

Retrieving Asset Universe, note there are no Relationships:
GET /servers/{serverName}/open-metadata/access-services/asset-catalog/users/{userId}/asset-universe/{assetGUID}

RESPONSE:
{
  "class": "AssetDescriptionResponse",
  "relatedHTTPCode": 200,
  "assetDescription": {
    "guid": "165ff2a0-f5b6-48cf-92bd-f7a40a54a3ba",
    "type": {
      "name": "DeployedDatabaseSchema",
      "description": "A collection of database tables and views running in a database server.",
      "version": 1
    },
    "createdBy": "dataPlatformOmas",
    "createTime": "2020-03-30T10:29:55.444+0000",
    "version": 1,
    "status": "Active",
    "properties": {
      "owner": "Owner Info",
      "qualifiedName": "test-DeployedDatabaseSchema",
      "name": "test-DeployedDatabaseSchema",
      "description": "Description"
    },
    "relationships": []
  }
}

Searching for the TabSchema/TabColumn entities with the search string "Tab":
POST /servers/{serverName}/open-metadata/access-services/asset-catalog/users/{userId}/search?searchCriteria=Tab
{
  "pageSize": 10,
  "from": 0,
  "level": 1,
  "entityTypes": [
    "Referenceable"
  ]
}

RESPONSE:
{
  "class": "AssetListResponse",
  "relatedHTTPCode": 200,
  "assetElementsList": []
}

Sorry this has taken so long to look at - just noticed yesterday that it had been assigned to me.
I have looked at the code and I can see a number of issues:

The tables are not being created
The userId being used is a hard-coded value
The DeployedDatabaseSchema is being created as a local cohort entity rather than belonging to the external database.
There is no mechanism for creating the associated asset nor connection.

Hope to get this fixed in the next 2 weeks.

The Data Platform OMAS has been replaced by the Data Manager OMAS.


[Website] AS selection should dissapear upon Simulation

If you've selected an AS, after clicking simulate that AS should be deselected since that pushes the diagram PNG out of view and is likely no longer relevant if the user is running the simulation (after all, they are clicking away from that box). They can always select that AS again if need be.

Fixed


🚸 IMPROVE: kitQL codegen - Provide (generic?) type for stores

Package graphql-codegen

[ ] KQL stores should maybe have a type (ideally generic).

Example:

with Sveltekit I can pass a store as a param, e.g a Writable

when it comes to a KQL custom store, i have no type to provide.
export const storyblok = (node: HTMLElement, storyStore: KQLStore<PageDetailFragment>) => {
   // I do things here including using storyStore.patch
}

Nice one 👍
Will you work on it? 🙃

I was having a look but i'm not familiar with codegen... 😄 Just have to figure out where i can get the return type of a query document... 🤔

🙃 I let you have fun with console.log a bit then 😂

What about
function myCoolFunction(store: typeof KQL_AllContinents) {
	store.resetCache();
}

😯

Works fines using typeof, I do not need more since this is for a very specific usage. 🎉


Dot-notation representation data requires parent entries

/**
 * @api-data preferences.videos.privacy.view (string) - The users' video view privacy preference.
 */

With an annotation like this, the API Blueprint generator requires that separate @api-data annotations are in place for preferences, preferences.videos, and preferences.videos.privacy or else what's generated in the API Blueprint file is just:
- `preferences` (object)

This bug only exists if there isn't anything else in the tree of that object. So if we add preferences.videos.privacy.something, the full tree will be present in the Blueprint.


winrate drops to 0

Figure out why the winrate drops to zero at high learning rate and fix it.
Maybe neuron weights are diverging or different network settings are needed.
In the case of divirging weights, maybe add regularization?
In any case, try to catch it.
Maybe automatic detection?

Maybe not really a bug, more of an anomoly

The weights are not dropping to zero or go to infinity

Making test game player against network

The original TicTacToe game experiences the same 'bug' when the parameters are set properly. For example: layers 81,81,81 and learn rate 1e-1, batch size 1000 also ends up having a win rate of 0.
There seems to be a turning point from where it can still 'save himself' from having a 0 win rate for the future. Using learn rate 7e-2 is still doable for ttt.

While reading more about the methods used for AlphaZero I found out that using only self-play with a RL agent tends to becomes instable in general (using the widely used policy gradient and q learning methods). Therefore, AlphaZero uses other techniques. Maybe interesting to do something with that?
https://www.reddit.com/r/MachineLearning/comments/76xjb5/ama_we_are_david_silver_and_julian_schrittwieser/


extraPolicies doesn't work on firefox-devedition-bin

Describe the bug
firefox-devedition-bin doesn't read the generated policy.json file that firefox-devedition and firefox-bin both successfully read.
Steps To Reproduce
Steps to reproduce the behavior:

nix-build --expr 'with import <nixpkgs> {}; firefox-devedition.override { extraPolicies.DisableTelemetry = true; }'
run result/bin/firefox
go to about:policies and notice that DisableTelemetry is set
nix-build --expr 'with import <nixpkgs> {}; firefox-bin.override { extraPolicies.DisableTelemetry = true; }'
run result/bin/firefox
go to about:policies and notice that DisableTelemetry is set
nix-build --expr 'with import <nixpkgs> {}; firefox-devedition-bin.override { extraPolicies.DisableTelemetry = true; }'
run result/bin/firefox-developer-edition
go to about:policies... uh oh

Expected behavior
extraPolicies should work consistently across Firefox packages.
Notify maintainers
@taku0 @lovesegfault
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.4.15-xanmod1, NixOS, 23.05 (Stoat), 23.05.4335.898cb2064b6e`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.5`
 - channels(root): `"nixos-23.05"`
 - channels(ryan): `"home-manager-23.05.tar.gz, nixos-unstable"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Going through steps 1-3 on my system, the policies don't seem to work even on the non-bin version.

+1 for librewolf
You can define a package overrride, but it has no effect.


User.unixid defaults to next highest available user id

Simply sets the unixid to the next available unixid

Thanks for contributing, Had the same thing on my todo list :)
Do you think we should also check for unixids that might have become available after you deleted a group or user and maybe allow to set the default using environment variables?

I think probably re-using unixids opens up a whole bunch of potential problems. Ideally there's be an internal counter saying what the highest unixid (in a particular range) ever was, and making sure to use a completely fresh unix id ever time.
The problem with id re-use, as I see it, is that there might be files owned by that unixid somewhere on the file system and we don't want people to accidentally inherent ownership of them.
I think this is a reasonable balance of easy to do (no new database tables) while also approximating the ideal behavior (use a new unixid every time, pick one from a user-defined range). There's a lot of features I'd like to add to this, so I think keeping it simple is probably better for now?


fix: replace colors with chalk

Fixes #948.

Codecov Report

Merging #949 (75f3fc1) into master (5e48a60) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #949   +/-   ##
=======================================
  Coverage   76.38%   76.38%
=======================================
  Files          19       19
  Lines         686      686
  Branches      131      131
=======================================
  Hits          524      524
  Misses        118      118
  Partials       44       44

Continue to review full report at Codecov.

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


Question about Trained Predictive Model for Major Class (Sec/SPI)

Hi USPNet Team,
I saw in the README that you have a model focused on the major class (Sec/SPI) with higher accuracy. However, I didn't see this model mentioned in your paper. Was this model used for any of the results in the paper? If not, do you have any performance results for it, especially compared to tools like SignalP?
Thanks!
Mechiel

Hi Mechiel,
Thank you for reaching out!
Yes, we do have a trained predictive model specifically targeting the major class (Sec/SPI) with higher accuracy. This model can be downloaded via the link provided in the README. However, it was not used for any of the results presented in our paper.
This model shares the same architecture as USPNet-fast and utilizes ESM-2 embeddings. To evaluate its performance, you can test it using the same code files used for the test and inference of USPNet-fast (requires organism group information). This will allow you to compare its results with other tools, such as SignalP.
If you have any further questions or need additional assistance, feel free to ask.
Thank you!


Multiple fixes on the same location looks a bit odd

Perhaps there is a way to resolve this by neglecting fixes on the same location using accuracy, but only updating the timestamp.

The problem is these are most likely not exactly the same locations. For that feature we have a very crude server-side "cluster" feature, however that basically only works with a minimum distance of 1 km.
But I agree, it would be better to use the map engine's clustering feature: https://maplibre.org/maplibre-gl-js/docs/examples/cluster/


[Distributed] Teach async let about implicitly throwing distributed…

… methods
Call to a distributed method is implicitly throwing, so in async let
context throws should be propagated to the binding itself from initializer.
Resolves: rdar://83610106

Another way of implementing it might be to add explicit throws flag to the function type associated when a outermost call in initializer context if it's a distributed function but it seemed like an overkill...

Hm, it seems like a distributed method at any level needs to be marked as throwing in async let context. Did some more experiments with this, going to update the PR.

Ok, made is so distributed method calls are marked as implicitly throwing in any position inside of async let initializer.

@swift-ci please smoke test

The problem with this approach, and I didn't realize it, that "local" method calls are not supported to throw unless they are explicitly declared as throwing. Going to close this one for now since making local refs work requires a different approach.


gnu-cobol: 3.1.2 -> 3.2, rename, reformat, add NIST tests

Description of changes

Update gnu-cobol to 3.2.
Rename to gnucobol as that's the way it's written in the project homepage
Move to pkgs/by-name
Update aliases
Update all-packages
Add the NIST tests for a broader testing
Remove skipped tests as currently no tests fail
Download package using the GNU mirror
Point homepage to the GNU redirect (points to sourceforge now, may change later)
Add myself to maintainers, as this is an interesting project with low pace of updates. I'll be glad to keep it updated.

Closes #275665
Very extensive changeset from upstream:Changelog
NEWS - user visible changes				-- outline --
GnuCOBOL 3.2     (20230728)
GnuCOBOL 3.2rc1  (20230118)
GnuCOBOL 3.2rc2  (20230210)

New GnuCOBOL features

Support for LINE SEQUENTIAL file type as per COBOL 2023

OPEN INPUT-OUTPUT and REWRITE are allowed (note that INPUT-OUTPUT
leads to slower IO for LINE SEQUENTIAL files)
validation of data on (RE-)WRITE and READ, active by default,
can be adjusted with the new runtime option COB_LS_VALIDATE

New intrinsic functions
BIT-OF, BIT-TO-CHAR, HEX-OF, HEX-TO-CHAR

Support for COBOL 2023 directive COBOL-WORDS

Support for bit operations according to COBOL 2023 with MF compatibility

Support for additional $SET directives: ODOSLIDE

Support for the EXTFH has been greatly enhanched and now includes support
for FH--FCD and FH--KEYDEF, fixed use of different attributes and changing
pointers and now supports - for 32-bit builds - an internal conversion
between FCD2 and FCD3 for cases where existing programs are coded with FCD2

OCCURS with multiple VALUEs supported (BS2000 format, FROM and TO pending)

new function to call COBOL from C that doesn't abort the program in case
of runtime errors or STOP RUN: cob_call_with_exception_check()

Support for the GCOS 7 (Bull) dialect, including:

PICTURE strings with L character (variable length fields)
CONTROL DIVISION with SUBSTITUTION SECTION (full support) and DEFAULT
SECTION (partial support)

Multiple sequential files can be concatenated by specifying multiple
files with a separator in the ASSIGN name (either directly or via
environment), see the new runtime options
COB_SEQ_CONCAT_NAME (defaults to false) and COB_SEQ_CONCAT_SEP

Initial "testing support" of CODE-SET clause to convert between ASCII and
EBCDIC on READ/WRITE/REWRITE for sequential and line-sequential files

Initial "testing support" of FLOAT-EXTENDED (long double type)

minimal "parsing support" for USAGE UTF-8 and UTF-8 literals

Support to exit the runtime from COBOL as hard error (including possible
[core-]dump and stacktrace) with "STOP ERROR" statement or by
CALL "CBL_RUNTIME_ERROR"

COB_PHYSICAL_CANCEL can now be configured as "never" to prevent unloading
of COBOL modules, both on CANCEL and on process exit, which is useful for
analysis tools such as callgrind or perf to keep all symbols until the end
of the COBOL process

the system function x'91' has been extended to support more functions

Changes that potentially effect existing programs:

ALLOCATE statement: earlier versions of GnuCOBOL initialized the memory
(to binary zero) if the INITIALIZED clause was not specified,
this isn't done anymore so if you need the memory to be initialized
specify that explicit in the source and recompile

variable-length RECORD SEQUENTIAL files, data validation on READ:
the length of the record as stored in the file is now checked for correct
format and is then compared against the record size defined in the program;
if the minimal record size specified is bigger, then the data is only
written up to the record length for that record, the other data is
undefined and io status 04 returned; if the record length is bigger than
the record size the record from the file is truncated, io status 04 set
and the following READ will start at the next record;
additionally on OPEN the length of the first record is read and if it
isn't within the above rulesan io status 39 is returned; as the default
format "COB_VARSEQ_TYPE = 0" contains two NULL bytes this will likely
make most LINE SEQUENTIAL files not declared as this type fail on OPEN

LINE SEQUENTIAL files, data validation: in case of bad printable data
(less than SPACE) a READ may result in io status 09 and WRITE may error
with io status 71; see the new runtime option COB_LS_VALIDATE to disable
this validation (= old behavior) and to increase performance on line
sequential file io;
if LS_NULLS is active and invalid data (bad encoded or missing encoding)
is found io status 71 is returned

LINE SEQUENTIAL files, handling of records that are "too long":
in case of "overflowing" records previous versions of GnuCOBOL cut the
data, set io status 00 and skipped the file until the next line
terminator is found;
the default changed (per COBOL 2023 and other compilers) so the data is
returned as "multiple" records and a warning (status 06) is issued;
setting COB_LS_SPLIT = false will have the old behaviour of truncating
the record, but will now set status 04

FUNCTION RANDOM: the internal randomizer was changed from "C" to "GMP"
this means that the sequence of random numbers are different when using
the same seed as versions before 3.2
while the changed use has the downside of taking longer for each seeding,
it provides a much better distributed sequence and increases portability
(switching to a different "C" runtime or operating system won't change the
sequences); additional the implementor-defined default seeding was changed
from "0 in most cases" to a random seed;
if you want the return values to be identical you always need to specify
a seed (including possibly 0);
the old behaviour can be enforced by compiling GnuCOBOL with
LIBCOB_CPPFLAGS=-DDISABLE_GMP_RANDOM

FUNCTION EXCEPTION-LOCATION: if the source raising an exception was not
compiled with location information this function previously returned
a single space; GnuCOBOL now always returns the module name, a procedure-
name " " and the source (line) identifier "0"

FUNCTIONs NUMVAL, NUMVAL-C, NUMVAL-F: if the argument does not match the
argument rules previous versions returned zero; now invalid data is skipped;
for example: "1. A-0B4.5" now returns -1.045 (or -1045 when the
DECIMAL-POINT IS COMMA clause is in effect);
as with previous versions the argument can be validated before using the
FUNCTIONs TEST-NUMVAL, TEST-NUMVAL-C, TEST-NUMVAL-F or the exception can
be checked afterwards using the EXCEPTION related functions;
the old behaviour can be enforced by compiling GnuCOBOL with
LIBCOB_CPPFLAGS=-DINVALID_NUMVAL_IS_ZERO

Handling of invalid numeric USAGE DISPLAY data:
previously the complete character was inspected and adjusted for conversion,
now only the second half-byte is used;
this yields in different results, for example both the zero and space
character in both ASCII and EBCDIC charset will now result in a numeric
zero; previously invalid data could result in huge or negative numbers in
internal intermediate items;
as this was both adjusted in the runtime and in the the generated modules
invalid data may have additional unexpected results if programs are not
recompiled

ORGANIZATION INDEXED (with BDB backend): internal changes in record and
file locking, fixing some related bugs

extended screen io with PDCurses (most Win32 builds): blink and bolding
are now enabled, when supported

extended screen io: support for color codes 8-15 (implied highlight/blink
attribute); only the three lower bits are now considered during evaluation
of the color-number, leading to a previous value of 21 (which was ignored
until now) being interpreted as 5, see FR #387

extended screen io with single-fields: runtime-adjustable attributes by
support of extension clauses COLOR and CONTROL for ACCEPT and DISPLAY
statements, see FR #189 + FR #355; note: while COLOR and CONTROL are parsed
for SCREEN SECTION they are ignored at runtime

extended screen io with single-fields: the ACCEPT statement now supports
the extension CURSOR clause, additional to the standard-defined
CONTROL phrase in SPECIAL-NAMES

the programmable runtime switches "SWITCH A" through "SWITCH Z" internally
used 1-26 and now use 11-36 to be able to combine then with switches 0-7;
if you set those via COB_SWITCH environment variables you need to adjust
their numbers

Changes that potentially effect recompilation of existing programs:

the reserved word list and intrinsic functions was updated, especially
to cater for new features of COBOL 2023; if compiling with any non-strict
dialect you may need to unreserve any conflicting words / functions

in 64-bit environments, the default size for BY VALUE parameters has changed:
If no explicit SIZE IS clause is specified,
old behavior: parameter passed as 32-bit value
new behavior: parameter passed as 64-bit value
To specify a 32-bit BY VALUE parameter, change the COBOL source to use
SIZE IS 4.  To continue to rely on the default size, both caller and
callee modules that use BY VALUE must be compiled with the same version of
GnuCOBOL, either prior this release, or since.

cobc now uses a two-pass preprocessing algorithm, where replacements for
COPY-REPLACING are done in a first pass, and the replacements for
REPLACE are done in a second pass. Note that, however, both
statements are parsed before the first replacement pass, so
COPY-REPLACING cannot impact a REPLACE statement itself.

Changes to the COBOL compiler (cobc) options:

new -fformat dialect option, and extended SOURCE FORMAT directives,
with the following newly supported reference-formats (in addition
to FIXED/FREE):
COBOL85      Fixed-form format with enforcement of Area A
COBOLX       GCOS 7 extended format
CRT          ICOBOL Free-form format
TERMINAL     ACUCOBOL-GT Terminal format
VARIABLE     Micro Focus Variable Fixed-form format
XCARD        ICOBOL xCard (extended card) format
XOPEN        X/Open Free-form format
These formats come with Area A enforcement (except for XOPEN), that
checks whether division, section, and paragraph names start in Area
A (i.e, before margin B), and so do level indicators FD, SD, RD,
and CD, and level numbers 01, and 77.  The underlying checks are
enabled or disabled by default using dialect option areacheck,
and then with $SET AREACHECK and $SET NOAREACHECK compiler
directives.
As a result of reference format being a dialect option, Area A
enforcement is available and enabled by default for dialects BS2000
COBOL, CA Realia II, COBOL85, GCOS COBOL, IBM COBOL, MVS/VM COBOL,
RM-COBOL, and X/Open COBOL.
Area A enforcement additionally enables detection of missing
periods before level numbers that lie in Area A in the DATA
DIVISION, and before paragraph and section names in the PROCEDURE
DIVISION.  More generally, some, but not all, missing periods can
be reported and recovered from.  This is configurable with option
missing-period.
If not specified, the compiler tries to automatically recognize the format,
using either fixed or free, depending on column 7 in the first non-space
line. This feature can be disabled by setting the format manually
with -free, -fixed or -fformat.

the new -febcdic-table option enables one to specify the
translation table used when dealing with EBCDIC codeset;
these translation tables are stored as new configuration files with
an extension of ".ttbl", currently available tables are:
default    translation to extended ASCII as per MF
alternate  translation from restricted ASCII only
ebcdic500_ascii7bit   EBCDIC 500 <-> 7-bit ASCII as per IBM
ebcdic500_ascii8bit   EBCDIC 500 <-> 8-bit ASCII as per GCOS7
ebcdic500_latin1      EBCDIC 500 <-> latin-1 as per iconv
This option supersedes the -falternate-ebcdic flag (still available
for backwards compatibility), which is equivalent to
-febcdic-table=alternate.

the compile flag -fodoslide was moved to a dialect configuration,
while -fodoslide still works as before it is now implied with
-std=ibm/mvs/bs2000, if you use those dialects consider to recompile
affected programs (with OCCURS DEPENDING ON) or compile with additional
-fno-odoslide to get the same results as with older GnuCOBOL versions

the compile flag -fdefaultbyte (initialization for data-items without
an explicit VALUE) was moved to a dialect configuration;
while -fdefaultbyte still works as before it is now implied as binary
zero with -std=ibm/mvs/bs2000/realia, space for -std=mf/acu/rm, and
no defined initialization for -std=cobol85/cobol2002/cobol2014/xopen,
it is unchanged for -std=default (initialize to PICTURE/USAGE);
for compatibility to previous behavior compile with -fdefaultbyte=init;
note that initialization for INDEXED BY items honors the defaultbyte
configuration now, too

new dialect init-justified that applies right justification by JUSTIFIED
clause for VALUE clause; this is applied to IBM dialects, if you want
the previous behavior compile with -fno-init-justified

depending on the new dialect option "using-optional" (included in the
the default dialect), checks for arguments not passed are now done (only)
on CALL, not on their (possibly many) references; if you want the old
"postponed" check either specify the parameter as OPTIONAL or use
-fusing-optional=skip; note: the non-strict dialects will raise a warning
on the first use of this feature, then automatically enable it

the dialect configuration option larger-redefines-ok was replaced by
the support option larger-redefines; if specified on the command-line
it is now -f[no-]larger-redefines instead of -f[no-]larger-redefines-ok,
which allows to also raise a warning for those with -flarger-redefines=warn
Note: the short one works both in current and older versions of cobc

the subscript checking enabled with -fec=bound-subscript (implied with
--debug) now generates checks depending on the new dialect configuration
option subscript-check if OCCURS DEPNDING ON is used;
the full check according to ISO COBOL, which checks against the ODO item
is still used in the default dialect, but several dialects now only check
against the maximum only

the GnuCOBOL extension of auto-adding the RECURSIVE attribute
if a program potentially calls its own PROGRAM-ID was moved
to a dialect option; it is now only active with -std=default
(and raises a warning as previously with -Wextra); if you want
to use this extension for other dialects use the new
-fself-call-recursive=warning (or "ok")

the option -g does no longer imply -fsource-location; but it auto-includes
references to the COBOL-paragraphs to further ease source level debugging

-fsource-location generates source references to copyboooks in DATA
DIVISION, enabling to inspect the initial VALUE setting as well as
"list"ing those copybooks with a source level debugger

new flag -fstack-extended (implied with --debug and --dump) to include
the origin of entrypoints and PERFORM, this is used for the internal
stack trace on abort and can be used for improved source level debugging

new flag -fmemory-check (implied with --debug) to do some validation
of internal memory used during CALL; this can help in finding otherwise
hard to diagnose overwrite of memory and as it is only done on CALL
has a much smaller footprint than -fec=bounds (as both check different
aspects at different places it is also reasonable to use both);
to disable it use -fmemory-check=none or limit by -fmemory-check=pointer

the option -g does no longer imply -fno-remove-unreachable; if you want to
keep those in you need to explicit specify this

the option -O0 now implies -fno-remove-unreachable

new options to ensure structured code-flow:
-fsection-exit-check to ensure sections don't "fall through" (are always
entered and left by PERFORM)
-fimplicit-goback-check to ensure modules are not left by implicit GOBACK
at end of PROCEDURE DIVISION

adjustments to warning options:
-Wconstant-expression was changed to a group warning and includes
the new, previously integrated, -Wconstant-numlit-expression
-Wtyping as a new warning raises only very suspicious MOVEs,
-Wstrict-typing, which will warn as before even for MOVE 1 TO PICX-FLD
is not included in -Wall any more
-Wlarger-01-redefines as new warning (enabled by -Wextra) to check for
the only larger REDEFINES that is explicit allowed by the COBOL standard
-Wno-unsupported -Wunsupported new option to disable or only warn
on use of features the runtime is not configured for;
this new option defaults to an error (= -Werror=unsupported)
-Wgoto-different-section as new warning (enabled by -Wall) to check for
GO TO that are likely to break the flow of PERFORM some-section
-Wgoto-section as new warning (enabled by default) to check for
GO TO a section instead of a paragraph; while allowed this is often
a coding error
-Wsuspicious-perform-thru (enabled by default) to check for PERFORM ranges
that are likely to create unwanted behaviour
-Wother now  warns for suspicious reference-modification which is likely to
create out-of-bounds access at runtime

new compiler command line option to list the known runtime exception names
and fatality cobc --list-exceptions

new compiler command line option -ftcmd to enable printing of the command
line in the source listing, -fno-timestamp to suppress printing of the time
and -ftittle to set a title instead of GnuCOBOL and version (_ chars are
replaced by spaces in the title)

new compiler command line option --coverage to instrument binaries
for coverage checks

the command line options -MT and -MF, which are used for creating a
dependency list (used copybooks) to be used for inclusion in Makefiles
or other processes, and which were removed in GnuCOBOL 2 are back in their
original version; note: their use will be adjusted where they don't match
GCC's same options in later versions, including addition of -M and -MD

new -std options:
gcos            GCOS compatibility
gcos-strict     GCOS compatibility                - strict
We define the GCOS dialect based on the COBOL85 standard, with new
dialect configuration options accompanying each specificity
introduced by the dialect.

new diagnostic format for errors: the diagnostics now print the source
code context with a left margin showing line numbers, configurable with
-fno-diagnostics-show-line-numbers, and possible to disable completely
with -fno-diagnostics-show-caret;
the option -fdiagnostics-plain-output was added to request that diagnostic
output look as plain as possible and stay more stable over time

the -P flag accepts - as argument for stdout

Important Bugfixes:

for dialects other than the GnuCOBOL default different reserved "alias" words
were not usable, for example SYNCHRONIZED or COMPUTATIONAL. This was fixed
and reserved words updated for the dialects "acu" (to ACUCOBOL-GT 10.4),
"ibm" (to Enterprise COBOL 6.3) and "mf" (to Micro Focus Visual COBOL 6.0)

for all "lax" varants SYNC was handled even if commonly ignored by the strict
dialects, this was fixed so SYNC is ignored depending on the dialect

COBOL programs compiled with versions before GnuCOBOL 3 that used files with
ORGANIZATION INDEXED or RELATIVE crashed when executed with newer versions,
this has been fixed so that all modules compiled with GnuCOBOL 2.2 can be
executed with GnuCOBOL 3.2

FUNCTION RANDOM could return 1 in rare cases (more likely on win32),
it now returns a value in the range 0 <= x < 1, as defined

the internal signal handler could crash or deadlock the process on hard
errors (either in called library functions or when running COBOL without
runtime checks); the signal handling is now completely rewritten to fix
this issue and all executed code from the signal handler but the COBOL data
dump is now signal and thread safe

TYPEDEF items got storage and attribute assigned, leading to bigger modules,
longer loading time and longer compile times; if you use those a recompile
is highly suggested

several bugs in COPY REPLACING / REPLACING were fixed along with adding
support for exensions related to REPLACING LEADING / TRAILING

for PICTURE P several fixes were made, so results may vary compared with
previous versions; sources with leading P never worked correct before,
and must be recompiled after upgrading

since its addition to GnuCOBOL ROUNDING MODE PROHIBITED just prevented
rounding; its behaviour changed to match the specification by doing that,
raising EC-SIZE-TRUNCATION and changed: not adjust the target field if
rounding would be necessary to store the data

Listing changes

the timestamp in the header was changed from ANSI date format like
"Tue Sep 28 09:49:43 2021" to formatted time (year after day); this may be
changed during configure with adding a define to COBC_CPPFLAGS;
to either use the old format, adding add -DLISTING_TIMESTAMP_ANSI,
or to use an explicit format (cut at 26 characters, may raise false-positives
in listing tests) e.g. date only -DLISTING_TIMESTAMP_FORMAT="%Y-%m-%d"

new compile options to adjust the listing, see above

More notable changes

in general, the maximum field size in LINKAGE SECTION was increased from
268435456 bytes (999999998 bytes for OCCURS UNBOUNDED) to the system
specific INT_MAX - 1, which is commonly 2 GB

in 64-bit environments, the maximum field size outside of LINKAGE SECTION
was increased from 268435456 bytes to 2 GB

numeric DISPLAY can store and may contain a positive zero after arithmetic,
PACKED-DECIMAL may contain negative zero (x'0D') after arithmetic; as before
numeric comparisions to ZERO / 0 / +0 / -0 will all be identical

quotes around filenames and parts that are resolved by environment variables
are internally ignored

the exception check for EC-PROGRAM-ARG-MISMATCH is now generated, validating
that non-optional PROCEDURE DIVISION USING items are passed and that their
size in the caller is at least as big as in the program

in case of any runtime features being used that are not available an error
is generated during compile (may be reduced to a warning by -Wunsupported
or be suppressed by -Wno-unsupported) and if the feature is actually used
at runtime a related exception status is set

the call-stack show on error and/or in the dump file now contains all
parameters given to the program via command line options, if any;
if full debugging information is available it includes all PERFORMs executed

the dump that is created on abort for all programs that were compiled with
-fdump can be explicit disabled by setting COB_DUMP_FILE=NONE; it is
automatically disabled if the process ends upon signals SIGINT/SIGTERM and
now also disabled upon SIGHUP/SIGPIPE

additional or instead of the internal COBOL dump a coredump file may be
created on runtime errors and when configured in the system also after
the signal handler; see the new runtime option COB_CORE_ON_ERROR for
details (the default is a best match to the old behavior)

source references shown in diagnostic messages and for trace at runtime
as well as during debugging were extended, for example each executed WHEN,
VARYING and UNTIL phrases are now seen

condition-names are made available for source-level debugging

cobc's parsing time was significantly reduced for big programs

execution times were significantly reduced for the following:
INSPECT that use big COBOL fields (multiple KB)
MOVE and comparisions in general (especially with enabled runtime
checks, to optimize those a re-compile is needed)
CALL data-item, and first time for each CALL
ACCEPT DATE/TIME/DAY, most if numeric items are accepted
datetime related FUNCTIONs
runtime checks for use of LINKAGE/BASED fields and/or
subscripts/reference-modification (re-compile needed)
general: execution of programs generated with -fsource-location
(implied with --debug and -fec), especially when many "simple"
statements or lot of sections/paragraphs are used (re-compile needed)

New system functions
CBL_GC_SET_SCR_SIZE  option to resize extended screen

New build features

configure now honors BDB_LIBS and BDB_CFLAGS
configure now honors MATH_LIBS
configure now checks for XCurses and allows --with-curses=xcurses
(experimental)
configure now checks for PERL and passes that as default to make test
cobc handles SOURCE_DATE_EPOCH now, allowing to override timestamps in
generated code and listing files, allowing reproducible builds of both
GnuCOBOL (extras folder) and COBOL programs

Obsolete features (will be removed in the next version if no explicit user
requests are raised)

use of old non-GMP randomizer for FUNCTION RANDOM

undocumented option -tsymbols, which was replaced by -ftsymbols in 3.0

Known issues in 3.2 (and 3.1)

testsuite:

if built with vbisam, cisam or disam, depending on the version used, some
tests will lead to UNEXPECTED PASS, while others may fail
possibly failing tests (false positives):

temporary path invalid
compiler outputs (assembler)
compile from stdin

NIST: OBNC1M.CBL false positive (the test runner uses a nonportable way of
emulating a program kill)
if build with -fsanitize, then some tests will fail; while we accept patches
to improve that, we don't consider the failing tests as bug in GnuCOBOL

the recent additions of ">> TURN" and "variable LIKE variable" may not work
as expected in all cases

floating-point comparison for equality may return unexpected results as it
involves a necessary tolerance; you may adjust the default tolerance of
0.0000001 by compiling GnuCOBOL for example with
LIBCOB_CPPFLAGS="-DCOB_FLOAT_DELTA=0.0000000000001";
we seek input for a reasonable default for GnuCOBOL 4 (use the mailing list
or discussion board to share your comments on this topic, keeping in mind
that this has to take both mathematical and "C compiler portability" into
account)

variables containing PICTURE symbol P may lead to wrong results in rare
cases (especially screenio) - please send a bug report if you catch a case;
since GC 3.2 rc3 all arithmetic operations and MOVE are believed to be
correct

features that are known to not be portable to every environment yet
(especially when using a different compiler than GCC)

function with variable-length RETURNING item
USAGE POINTER, which may need to be manually aligned

all versions of GnuCOBOL so far: EVALUATE evaluates all subjects on each
WHEN (the standard explicit requests a one-time evaluation of the subjects,
then comparing the value); to work around possible issues move more complex
subjects like variables with subscripts and reference-modification, as well
as calculated subjects and function calls to a temporary variable and use
this as subject for the EVALUATE

For more known issues see the bug tracker.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Can you split the file move into another commit, and do it with git mv?
That way we don't lose all the history.

Can you split the file move into another commit, and do it with git mv?
That way we don't lose all the history.

Done. I erroneously assumed the history was there, but you are right, it was lost as it was tracked as a file delete. Not anymore now that the file move is in its own commit.

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

4 packages built:

gnucobol
gnucobol.bin
gnucobol.dev
gnucobol.lib

Result of nixpkgs-review pr 325294 run on aarch64-linux 1

4 packages failed to build:

gnucobol
gnucobol.bin
gnucobol.dev
gnucobol.lib

This is the test that fails on aarch64:
gnucobol> 843: runtime check: write to internal storage (1)    FAILED (run_misc.at:14180)

This is the test that fails on aarch64:
gnucobol> 843: runtime check: write to internal storage (1)    FAILED (run_misc.at:14180)

Thanks for reporting this. I'm updating the package to skip that test on aarch64, as I could replicate the failure.

Updated to 3.2 by #328342.

@kiike my appologies for missing this PR before submitting mine. I can resubmit this PR on your behalf if you'd like.

@kiike my appologies for missing this PR before submitting mine. I can resubmit this PR on your behalf if you'd like.

Sorry for the delay. Please do feel free to submit the changes again.


feat: add support for Auto IP

This commit restores a legacy behavior of the v1 Proxy, this time behind the flag --auto-ip. When the flag is enabled, the Proxy will first attempt to use a public IP. If no public IP is present, the Proxy will second attemtp to use a private IP. If neither is present, the Proxy errors as expected.
This new flag is primarily to support legacy behavior and should not be used in production otherwise.
Fixes #1732.

We need to add this option to the FUSE path as well. Currently FUSE assumes public IP always.


feat: add DisableEvents option

Adds an option to disable event collection but keep data synchronisation, defaulting to the current behaviour of both online.
Also fixes some incorrect test names.
resolves #20

Could someone please review this?
@deleteLater @cosmic-flood @cosmos-explorer

Could someone please review this? @deleteLater @cosmic-flood @cosmos-explorer

Sorry, we missed this pull request. We will review it these days.

I will review this today

LGTM! Thanks @ghelyar ❤

I've released version 1.2.2, which includes this feature.

Thanks 👍


Renamed networkBehaviours to networkBehavioursCache to reduce confusion

No functionality changes. Figuring out when we should use cache and when we shouldnt is for another PR. This is just to make the name less confusing, because before the two names were identical except for capitalization of the first letter.

:tada: This PR is included in version 3.5.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Not working on my HTML file?

Tried every possible way to get it through but failed.

Also not working for me. Error in console:
Uncaught TypeError: Cannot read properties of null (reading 'replace')
    at p (default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1:7314)
    at default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1:5951
    at s (default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1:5168)
    at l (default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1:5850)
    at default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1:7280
    at default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1:7358
p @ default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1
(anonymous) @ default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1
s @ default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1
l @ default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1
(anonymous) @ default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1
(anonymous) @ default.html?user=CDWimmer&identity=ghcard-CDWimmer-1:1

Same here!


new marks at the top

Hey! awesone extension! Thanks for this.
I'm wondering if there is a way to make harpoon insert new marks at the top of the quick menu instead of the bottom?
Usually I jump back more often to the marks I just created.
Thanks and sorry if this is possible already, but I couldn't find how.

think problem with this is that your marks will be moving every time you add(mark) new file.. so e.g. ui.nav_file(1) leads to new file every time instead of being static. But anyway, think it would be great to people who dont use jumping like that, to add some boolean option to force adding new file to top of buffer)

yeah, I represent this more as stack of latest marks. that seems more natural to me. An option would be perfect

As a suggestion, you could create a keymap which selects the the last marked file:
vim.keymap.set("n", "{lhs}", function()
    local marks = require("harpoon").get_mark_config().marks
    require("harpoon.ui").nav_file(#marks)
end)

With new updates, as i see , harpoon saves its last cursor position, so its comfortable enough now, at least for me


code coverage

Is it possible to show the code coverage when bats has been run?

In general you must use an external tool to do this. A tool specific to generate a code coverage report from the test execution.
I am about to try integrate some tool for code coverage into my own test, perhaps bashcov or kcov.
It seems like a discussion on code coverage is ongoing in the new repo for Bats.

Not sure if this is the right place to ask, but does anyone have an example (command and index.html output) of kcov working with bats???
Problem: When the following command is run (kcov being fed bats bash file with arguments):
kcov [outputdir]/coverage/ bats [bats_test_path]/test_AFF_Simple.bats
the OUTPUT is 0% code coverage for the "bats" only with 20 lines instrumented and 0 hit.
This is the file output:
Coverage Report
Command:batsLine numberDate:2018-06-13 19:44:55Instrumented lines:20HitsCode covered:0.0%Executed lines:0Order | Command: | bats | Line number | Date: | 2018-06-13 19:44:55 | Instrumented lines: | 20 | Hits | Code covered: | 0.0% | Executed lines: | 0 | Order
Command: | bats | Line number
Date: | 2018-06-13 19:44:55 | Instrumented lines: | 20 | Hits
Code covered: | 0.0% | Executed lines: | 0 | Order
#!/usr/bin/env bash
2
30 set -e
4
50 export BATS_READLINK='true'
60 if command -v 'greadlink' >/dev/null; then
70 BATS_READLINK='greadlink'
80 elif command -v 'readlink' >/dev/null; then
90 BATS_READLINK='readlink'
10 fi
11
12 bats_resolve_link() {
130 if ! "$BATS_READLINK" "$1"; then
140 return 0
15 fi
16 }
17
18 bats_absolute_path() {
190 local cwd="$PWD"
200 local path="$1"
210 local result="$2"
22
230 while [[ -n "$path" ]]; do
240 cd "${path%/}"
250 path="$(bats_resolve_link "${path##/}")"
26 done
27
280 printf -v "$result" -- '%s' "$PWD"
290 cd "$cwd"
30 }
31
320 export BATS_ROOT
330 bats_absolute_path "$0" 'BATS_ROOT'
340 BATS_ROOT="${BATS_ROOT%/*}"
350 exec "$BATS_ROOT/libexec/bats" "$@"
Any and ALL help is appreciated.
Note: I managed to get code coverage for PYTHON files; but NOT for BAT files....
Thanks,
-Alex

Is there any updates about the bats coverage?

@sunwei There isn't going to be any updates in this repo. I would advise you to move over to https://github.com/bats-core/bats-core, as that is where active development has moved after the call for maintainers in issue #150


Is workbox.routing.setDefaultHandler ignoring registered routes?

Hello,
i'm using workbox version 4.3.
I have a small piece of code:
workbox.routing.registerRoute(
  /(\/|)(index.php\/|)(login|register|dashboard|password_login|connection_test)(.*)/gm,
  new workbox.strategies.NetworkOnly()
);

workbox.routing.setDefaultHandler(
  new workbox.strategies.StaleWhileRevalidate()
);

When i set default handler all other defined routes will be ignored. Is that a expected behavior? If yes is there a workaround to exclude some pathes/urls from caching?

@bitterdev to clarify, are you saying the network only route you're defining first is not being used? And only the default route (defined second) is being used?

@philipwalton Sorry my mistake! I have enabled the debug mode and find out that there was another reason for my problem. You can close this ticket. Thank you.


Bug Report Title

ENFT Version
^1.0.6
Describe the Problem
It didn't notified of this NFT sold transaction.
Opensea: https://opensea.io/collection/opepen-edition
Contract Address
0x6339e5E072086621540D0362C4e3Cea0d643E114
Transaction Hash
0xa3f4e1ed59ef91bb7a67d3199092a812141b78b5c55d8219719d33340bd91cfd
Code Snippet
No response
Contract ABI
No response
Errors
No response
Environment
node.js (v16 or newer)
Environment (Other)
No response

Update the enft package to latest version.
npm install enft@latest

Thanks :)


wrong weekday

the widget is showing wrong weekday. For example, 2021-12-01 is Wednesday rather than Monday.

Thanks. I’ll check it.

This should be fixed in the latest release


V3.1 dev

add the coolhigh vehicle config file

No need to commit the canbus code again

@wfgsy101 resolve the conflict again


Server Blocked Upon Redis Failure

Hi,
I noticed when my Redis server fails or shuts down unexpectedly, my server is unable to accept any requests. It seems like the event loop is blocked with retry attempts to reconnect to Redis. Is there a way the server can continue to process requests/responses while periodically attempting to reconnect to the Redis server? Thanks!
[ioredis] Unhandled error event: Error: connect ECONNREFUSED <IP_ADDRESS>:6379
at Object._errnoException (util.js:1041:11)
at _exceptionWithHostPort (util.js:1064:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1153:14)

Refer to the retryStrategy option for details. By the way, the event loop was probably not blocked (if it was, you should notice the CPU usage of the process reached nearly 100%). Check the middleware or HTTP callbacks in your App to see whether the request handler will keep waiting for redis commands.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Michael Thai<EMAIL_ADDRESS>Sent: Tuesday, August 29, 2017 2:11:07 AM
To: luin/ioredis
Cc: Subscribed
Subject: [luin/ioredis] Server Blocked Upon Redis Failure (#514)
Hi,
I noticed when my Redis server fails or shuts down unexpectedly, my server is unable to accept any requests. It seems like the event loop is blocked with retry attempts to reconnect to Redis. Is there a way the server can continue to process requests/responses while periodically attempting to reconnect to the Redis server? Thanks!
[ioredis] Unhandled error event: Error: connect ECONNREFUSED <IP_ADDRESS>:6379
at Object._errnoException (util.js:1041:11)
at _exceptionWithHostPort (util.js:1064:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1153:14)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/luin/ioredis/issues/514, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAmz_htw-qi6OyyikWVux8nct90wCbXLks5scwK6gaJpZM4PE3ei.

@luin Do you happen to have a simple example the shows

HTTP callbacks in your App to see whether the request handler will keep waiting for redis commands


172 bug fixing tfb chats

I forgot to enable Bungee feature for ChatControl

For a hotfix of this scale I hope it was okay I self-approved it lol


Add panic version of common operations

I've found these Musts to be very useful in my projects so I thought I'd pitch it.
Feel free to object.

@govalues Could you please merge it? :)

Dear @dascapytal1559,
Thank you for your suggestion! I understand how "Must" methods can be convenient for simplifying code by avoiding explicit error handling. However, the primary goal of this package is to prioritize safety and robustness in decimal computations.
That said, I’d like to share a couple of suggestions that might help achieve similar convenience while keeping computations clear and panic-free:
"Function per Formula": Consider breaking down complex formulas into smaller functions. Each function can represent a meaningful part of the computation. This approach not only improves readability but also enhances maintainability by giving clear names to specific steps in the computation.
"Favor Composite Methods": Where possible, simplify your formulas algebraically to make use of the composite operations available in the library (e.g., Sub, Prod, AddMul, AddSub, SubMul, SubQuo). These methods are optimized for performance, accuracy, and readability.
I hope these suggestions are helpful!

I accept panic-free is a core tenent of this package but I also dont find the suggestions helpful in resolving my pain-point using this package. Thanks for considering anyway, I'll continue to run a fork for my usecases. Feel free to close the PR.


862 add programme history fields - first step

Context
Trello: Add additional programme history fields to API
Changes in this PR
Expanded the setting and outcome properties of CourseParticipationHistory

yearStarted has been moved to outcome, see below
setting now has var location: String? and var type: CourseSetting
outcome now has additional properties var yearStarted: Year? and var yearCompleted: Year?`

outcome has an additional unused private field
@Formula("0")
val ignoreMe: Int = 0

If all properties of an @Embedded object are null Hibernate will not create the object. Instead the property (outcome) is set null - even if it is not a nullable type! The additional field ignoreMe, which not nullable forces Hibernate to always populate the outcome property with an instance of CourseOutcome
The course_participation_history table has been renamed to course_participation
OpenAPI specifications provide an allOf keyword which provides an inheritance mechanism for component schemas.  allOf has been used to remove some of the redundancy in api.yml.
OpenApi Operation objects have an operationId field that name each operation. If an operationId on an operation then the kotlin-spring code generator uses the value of this field as the name of the generated method that handles this operation.  operationIds have been added to all the course-participation related operations in api.yml. Hopefully this makes the generated method names more readable. It also means that those method names do not change when the operation paths are changed.  A future refactoring could add operationIds to all operations in the api.yml specification.
Post-merge

[ ] Manually approve release to preprod
[ ] Manually approve release to prod

Now that #125 has been merged, this'll need rebasing to bring those changes in. Happy to pair on that to help get this over the line, I'm sure @nsmj63-dxw would be too.

Using this code as a template for a rewrite will be quicker and easier than trying to rebase.


Implement std::error::Error and std::fmt::Display for DotenvError

This would greatly aid writing generic code.
My specific use case is this (currently impossible):
IronError::new(err, format!("error: {}", err))

where err: DotenvError. IronError's constructor here is new<E: Error, M: Modifier<Response>>(e: E, m: M); the error gets stored in a Box<Error + Send> field.

This makes sense to me. It's been pending since forever, I think.

I actually had a go at implementing this, but eventually ran into a borrowck issue that I had no time to solve, so I just worked around it (by using my own Error struct in place of the DotenvError).


Where should +Z point in the Cartesian XYZ frame convention?

Following #15, we should have a discussion about the pros and cons of various orientations of the XYZ Cartesian frame in observer coordinates. If we are sticking to right-handed systems, there are basically two options

+Z points away from the observer. This is currently the way exoplanet is structured.
+Z points toward the observer. This is the way Murray and Corriea seem to have things.

There are some pros and cons to each system.
System 1 yields v_z = v_radial, in that positive radial velocities are receeding from the observer. However, matching up astrometric orbits is a little bit tricky because after we go from the x,y,z in the perifocal frame to the XYZ in the sky frame, we need to associate X and Y with RA and DEC appropriately. The observational definition is that if the position angle of the ascending node (Omega) is 0, then the node is located 0 degrees east of north. This makes the X axis correspond to the north axis, and so to conform to the right hand rule, since we usually draw north up and east to the left, the Y axis must point to the right, or Y = - RA axis. This means that mentally mapping a simple orbit in the perifocal plane to the observer frame requires a reflection about the X axis. I always found this a little bit confusing because when plotting orbits we typically invert the RA axis to have it increasing to the left. This convention would also have us negating it as well.
System 2 does better with associating X and Y with cardinal directions. The X axis still corresponds to north, but now Y points to the left, so Y = + RA axis. So mapping from the perifocal frame to the observer frame only requires a 90 degree rotation. This is easy enough to plot an orbit as plt.plot(Y, X). This system can't have it all, though, since now Z points towards the observer and so v_radial = - v_z.
Thoughts on which would make our lives easiest across all of the package?
Second, following the choice of where +Z points, is a discussion of which node is the ascending node, i.e., the one where the secondary is coming towards the observer, or the one where the secondary is receeding from the observer.
A third observational convention is that inclination is [0, 90) degrees when the orbit is counter-clockwise on the sky and (90, 180] degrees when the orbit is clockwise on the sky. For this reason I tend to prefer System 2 because it means the inclination is simply the angle between the angular momentum vector of the orbit and the +Z axis (pointed towards the observer).
Once we make decisions on the first two conventions then I think the rotation matrices from the perifocal frame to the observer frame are uniquely specified.

Excellent. I'm happy to switch to 2 where Z points towards the observer (I know that this is also what @rodluger wants…). Here's a list of some of the spots where we'll have to make changes:

[ ] exoplanet/theano_ops/starry/limbdark.cc: this currently has the transit == (z < 0) convention encoded
[ ] exoplanet/theano_ops/contact/contact.cc: the contact points for a transit are computed with the current definition
[ ] exoplanet/light_curves.py: defaults to passing los = -tt.ones_like(...) to get a transit
[ ] exoplanet/orbits/keplerian.py we'll have to incorporate the rotation matrices properly @iancze: since you're looking at this anyways, can you update the implementation and add the matrices that you're using somewhere in paper/exoplanet.tex or a notebook in docs/notebooks so that it'll go into the docs?
[ ] exoplanet/orbits/keplerian.py we'll have to audit the radial_velocity function
[ ] exoplanet/orbits/light_curve_test.py I think that the comparisons to batman might need to be updated because I think batman uses the old convention

I'm sure there are some other spots that we'll need to audit and we can add them here.

I've made the +Z change on the sign-conventions branch and everything looks good. The only inconsistency now is that radial velocity is -v_Z, but I think that I've updated that method to do the right thing and I've added a note to the docstring.

@dfm When do you plan on releasing a new version of exoplanet with this new convention? I'll have to switch some signs within my starry Ops when the time comes.

I think we're pretty set to go on this. Maybe next week? Perhaps we should make it a 0.2.x series since this is a backwards incompatible change.

Either way, I think we'll want to include en example of fitting astrometry so we'll wait until @iancze opens his pull request.

I think I have a working example for astrometry-only here (with and without parallax info): https://github.com/iancze/exoplanet/blob/keplerian-astrometric/docs/notebooks/astrometric.ipynb
[if you have any comments in the meantime, please point them out].
I'm still working on implementing the astrometric + RV fits, and struggling a little bit with the get_consistent_units function. I may open up a separate issue about expanding which combinations of parameters can be accepted. There're a lot of combos to work through and it's easy to lose track of what constitutes a minimal set and what is automatically calculated.

This notebook looks awesome! If we want to get crazy, we could add a mixture model to deal with outliers.


Add BurntSushi to libs reviewers

r? @nrc
(rust_highfive has picked a reviewer for you, use r? to override)


Allows calling methods with callback as last param

The main motivation behind this PR is to allow using a promise-based interface on top of this module.
The most common tools to promisify the async calls expect the callback to be the last argument but the SOAP methods are built with it in the second position, allowing a third and fourth optional params (options, and extraHeaders).
The proposed change allows more flexibility in method calls in order to support the following signatures:
// standard and documented method signatures
client.MyFunction(args, callback)
client.MyFunction(args, callback, options)
client.MyFunction(args, callback, options, extraHeaders)

// non-documented but supported signature
client.MyFunction(callback)

// new supported signatures with callback as last param
client.MyFunction(args, options, callback)
client.MyFunction(args, options, extraHeaders, callback)

Documentation has been updated and tests added.

Coverage increased (+0.2%) to 92.015% when pulling f8c99996ad9763b3c8437af42c76b6b99a05f22e on gabmontes:patch-3 into 49bc1c6d285ace5bde26f4743c66a0756d911090 on vpulim:master.

Thanks a lot @gabmontes - this seems like a really valuable addition to our library :+1:

@herom great to hear that! Thanks!!!


feat(table): add onRowClicked callback

Summary

Should be sending an onRowClicked event that's seprarate from the onRowExpanded or onRowSelected event

Change List (commits, features, bugs, etc)

add onRowClicked event

Related Issues

Closes IBM/carbon-addons-iot-react#67

Acceptance Test (how to verify the PR)

Check the storybooks and make sure the onRowClicked event is being sent when clicking on the row.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Recommended resolution support for D435 on USB 2.0 connections

Required Info

Camera Model
{ D400 }

Firmware Version
(<IP_ADDRESS>)

Operating System & Version
{Rasbian}

Kernel Version (Linux Only)
(4.16.??)

Platform
Raspberry Pi

SDK Version

Language
{C}

Segment
{others }

Issue Description
I realise that it is not possible to use the D435 with the recommended resolution of 848x480 on USB 2.0 systems.
Is it possible to add support for that as bandwidth is not an issue considering there is 1280x720 support on USB 2.0.

This is not an official answer as I do not work for Intel.  It is unlikely that another mode will be added to USB2 due to Intel wanting to keep in check the number of modes they support (partly because more modes means extra testing).  For example, it was recently stated that there are no plans to support 24 FPS.
In September 2018's RealSense online seminar, it was mentioned that a new 'Modified Huffman' lossless compression will enable the streaming of higher resolution and FPS on USB2, and more channels in multi-camera configurations.

I submitted this change request to development team. They will handle it in lower priority.
Actually for D435, 848x480 provides better depth.
Thanks ban1080 for the suggestion.

Thank you.
Yes, We'd like for 848x480 to be available on USB 2.0.


Added data-test for DR UI components

Signed-off-by: Gowtham Shanmugasundaram<EMAIL_ADDRESS>

@SanjalKatiyar changes done

/override ci/prow/odf-console-e2e-aws


🔥 Add Chrome Extension

Consider adding Chrome Extension.
Features:

You can download the Chat is currently opened in JSON or in Markdown.
You can Download all Chats in one JSON file or a Zip file containing all the markdowns.
Options page where offsets can be configure.
The log appears in the extension, showing the number of downloaded chats.

File Tree Explanation:
 +-----------------------------------+
 | ChatGPT-backup                    |
 |             +------+ +----------+ |
 | Backup All: | json | | markdown | |
 |             +------+ +----------+ |
 |             +------+ +----------+ |
 | Backup One: | json | | markdown | |
 |             +------+ +----------+ |
 +-----------------------------------+

 chrome-extention/
 ├── icons/
 │   ├── icon16.png
 │   ├── icon32.png
 │   ├── icon48.png
 │   └── icon128.png
 ├── options/
 │   ├── options.html ---------- Set StartOffset, EndOffset.
 │   └── options.js              and other markdown configs.
 ├── popup/
 │   ├── FileSaver.js ---------- Open Source tool to save (to maximize compatibility)
 │   ├── jsZip.js -------------- For Markdown back, will put them all in zip file.
 │   ├── popup.html  ----------- The Extension index.html (the entry point)
 │   └── popup.js
 ├── scripts/
 │   └── content-script.js
 ├── manifest.json  ------------ V3 type, permissions, etc.
 └── service-worker.js --------- Code that interacts with host (chat.openai.com) .

https://user-images.githubusercontent.com/45242501/231926413-573492b8-8142-4bbb-93ea-b9cb90a1ce59.mp4

Nice work. One thing I noticed is if I click away from the extension pop up it fails with error:
Uncaught (in promise) Error: Attempting to use a disconnected port object
    at getAllConversations (service-worker.js:218:10)
    at async main (service-worker.js:227:28)
getAllConversations @ service-worker.js:218
Promise.then (async)
(anonymous) @ service-worker.js:235

Nice work. One thing I noticed is if I click away from the extension pop up it fails with error:
Uncaught (in promise) Error: Attempting to use a disconnected port object
    at getAllConversations (service-worker.js:218:10)
    at async main (service-worker.js:227:28)
getAllConversations @ service-worker.js:218
Promise.then (async)
(anonymous) @ service-worker.js:235

After new commit, that shouldn't happen anymore.


FlowField Calculation Formula Using Field Added via TableExtension

I have added a new option field to the Sales Header with a tableextension. In a new table object I want to define a flowfield which counts the number of Sales Header records where the new option field has a certain value.
Referring to the new field in CalcFormula property gives the following error:
Reference '' in application object 'Sales Header' does not exist.

This should work. Can you please share your calc fomula?

I've actually deleted this object now as I realised I don't need it (it was part of a Cue table for a Role Centre), but this is an example of the issue:
field(2;"No. of Orders";integer)
{
FieldClass=FlowField;
CalcFormula=count("Sales Header" where("Credit Management Status"=const("Credit Held")));
}
"Credit Management Status" is a new option value added to the Sales Header table by a table extension object.
The error is "Reference 'Credit Held' in application object 'Sales Header' does not exist."

It looks like the same root cause as #195, we will look into it.


Something went wrong with release .10

The uploaded artifacts (source and aar) have the request method in base with the == not the latest >= on the sdk check..
Looks a bit like the wrong artifact got uploaded. the release zip is fine..

o0ops, i'm uploading new version right now  v.1.0.11

please update to v1.0.11
Thank you for your help.


VFIO does not notify MUSER for DMA unmap events

Becasue we no longer ping pages using vfio_pin_pages, VFIO doesn't sent MUSER DMA unmap events. This causes problems to libmuser because we get overlapping DMA regions we don't know how to properly handle, and also it's a resource leak. One way to deal with this is to hack VFIO blindly send the DMA unmap event (even if the driver hasn't pinned any page from that DMA region): https://www.redhat.com/archives/vfio-users/2020-February/msg00016.html.
Another way would be to not to use this hack and implicitly unmap the previous regions clobbered by the new region. The problem of this approach is that there can be leaks and handling of overlapping regions can be complicated. We need to check to see how VFIO handles overlapping regions.

I tried adding two overlapping DMA regions (0x000-0x2000 and 0x1000-0x3000) and this is failed with -EEXIST by vfio_dma_do_map in vfio_iommu_type1.c; the DMA map event doesn't reach MUSER at all. So the solution of implicitly unmapping existing regions could work, apart from the possibility of a leak. The possibility of a leak could be mitigated by unmapping the fd it hasn't been used for some time and then remapping it on demand.

We've switched to vfio-user and have dropped muser.ko.


cmd/run: mips: Go run on mips env with Illegal instruction

What version of Go are you using (go version)?

$ go version
1.16

CPU INFO
system type  : RTL8672
machine   : Unknown
processor  : 0
cpu model  : Taroko V0.2
BogoMIPS  : 597.60
wait instruction : no
microsecond timers : yes
tlb_entries  : 64
extra interrupt vector : no
hardware watchpoint : no
isa   : mips1
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
package   : 0
core   : 0

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/chenxiaoxi/Library/Caches/go-build"
GOENV="/Users/chenxiaoxi/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/xxx/Documents/dev/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/xxx/Documents/dev/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/xxx/Documents/dev/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/xxx/Documents/dev/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gn/5v1jyffj6mn0nk1w353lgmzm0000gn/T/go-build2714969011=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
compile with
GOOS=linux GOARCH=mips GOMIPS=softfloat go build -ldflags "-s -w"  -o probe-client ./probe-client.go

What did you expect to see?
run success
What did you see instead?
Illegal instruction

Does this work in 1.15?
Can you figure out what the illegal instruction is? That error looks like it is coming directly from the OS, not from the Go runtime. Which makes me think it is very early in startup, before the Go runtime can install the SIGILL handler (or, less likely, the OS is not delivering SIGILL correctly).
Can you run under a debugger and see where it stops?

isa   : mips1

If this is not lying, this ISA is really old. Go requires newer ISA (MIPS32r1+) to run.


Viewport: Unable to use parent world as world_2d

3.1.1.stable.official

Ubuntu 18.04

I want to have a viewport that renders the same scene as the main viewport but with a different camera. If I try to set the world_2d of the viewport as the main world_2d
vp2.world_2d =  get_viewport().world_2d
I get:
WARNING: set_world_2d: Unable to use parent world as world_2d
At: scene/main/viewport.cpp:963.
And it doesn't work.
However if I remove this check from the code everything works smoothly.
Is there any reason for this check?

@puthre I am having the same issue as the OP, but I do not understand how your pull request would close this issue?

@Asaurus1 it removes the check in  scene/main/viewport.cpp

Same here.
var default_viewport = get_viewport()
other_viewport.world_2d = other_viewport.world_2d

W 0:00:00.469   set_world_2d: Unable to use parent world as world_2d
<Fuente C++>  scene/main/viewport.cpp:1024 @ set_world_2d()

In 3.2.3.stable.official (Windows) I'm still seeing this issue - trying to set up a separate Camera2D to give another view on the same 2D world, and nothing shows up on-screen. Error reported is:
W 0:00:14.280   set_world_2d: Unable to use parent world as world_2d
<C++ Source>  scene/main/viewport.cpp:1024 @ set_world_2d()

same problem :(

same problem :(

Maybe if we make a PR just to remove the check in viewport.cpp, it'll be easier to aprove it.
That's gotta be an important use case. It's essential to put multiple 2d cameras rendering the same scene from different angles/positions, which is a pretty common use case IMO.

Heya, thank god for open source, I compiled 3.3 and made the change, sure enough, it worked, not sure why the check is there (maybe to prevent recursive viewports), any word on the change? Happy to make my first pull request on commenting 3 lines but I feel its a bit ignorant without understanding what that check was trying to prevent

Heya, thank god for open source, I compiled 3.3 and made the change, sure enough, it worked, not sure why the check is there (maybe to prevent recursive viewports), any word on the change? Happy to make my first pull request on commenting 3 lines but I feel its a bit ignorant without understanding what that check was trying to prevent

Feel free to open a pull request so we can discuss it there.

Let's revive this thread. I made the proposed PR.
The check was first introduced in https://github.com/godotengine/godot/commit/97cf3eba56f7f89b9a6b275c70e54e52303e25a7, maybe @Faless can shed some light on the subject ?
It would be cool to have in 2D the same structure as the example project for split screen: https://github.com/godotengine/godot-demo-projects/tree/master/viewport/dynamic_split_screen, which does not work now because of that check.

So I had time to test this further and it seems like it was a bad idea to remove that check, even though it may work in some cases.
I tested the splitscreen case from https://kidscancode.org/godot_recipes/2d/splitscreen_demo/, but adopted this structure

This results in some pretty wild artefacts:

Here is the project
splitscreen_start.zip

After checking https://github.com/godotengine/godot/pull/31877 I changed the type of the Viewports node to a CanvasLayer with layer = 1, and then it works as intended, because the viewports don't render what is inside the CanvasLayer and the recursion cycle is broken.
So this check could be removed but users will have to know the proper technique.
Or the full https://github.com/godotengine/godot/pull/31877 PR could be updated. I may be able to do it, but my C++ is pretty rusty, pun intended.

I think the correct way to do this is with the full PR (and using layer masks). The check should be removed once layer masks are in.
Personally, I'm looking at fixing up #31877 and matching feature parity with 3D/Spatial, I'd really like it for some clean rendering effects. I am about done with fixing the issues I had with the original PR (UI/Inputs on child Viewports) and some missing functions. Just have to port it to 4.0... 😅 Hopefully I can make a PR once I've done that and rounded out the documentation etc.

I motivated myself to update #31877 yesterday, it was not so bad: https://github.com/godotengine/godot/pull/52350.
What issues did you have with the original PR ?

Some missing functions on the gdscript side (I want to be able to do this without using nodes too), inability to nest viewports and take input properly and potentially unwanted differing behaviours vs Spatial node masking and CanvasItem masking. It's not terribly much different but I'm just fretting over getting it right. I have more time tonight to hopefully wrap it up. I've spent some time building a proper debug scene and trying to use the features in one of my projects to make sure I've gotten everything I'd need.

a
why isn't this closed yet

why isn't this closed yet

The issue is still relevant in both 3.x and master to my knowledge.


Add MoonGate wallet to Solana Labs wallet adapter

Published the first version of the MoonGate Wallet Adapter for Solana. MoonGate is an iFrame based MPC wallet similar to Torus Wallet enabling Ethereum users to be able to sign into Solana in just a few clicks.

Hey, please can you remove the changes to our starter apps? We deliberately don't include any named wallets in those.
Also I don't think we need the change to package.json, that dependency should just be for your wallet package right?

Hey  Callum,
Thanks for your response, I will get that updated and cleaned up.
On Tue, Oct 17, 2023 at 9:23 AM, Callum McIntyre @.***>
wrote:

Hey, please can you remove the changes to our starter apps? We
deliberately don't include any named wallets in those.
Also I don't think we need the change to package.json, that dependency
should just be for your wallet package right?
—
Reply to this email directly, view it on GitHub
https://github.com/solana-labs/wallet-adapter/pull/825#issuecomment-1765916480,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5YHRQKQST2LXJH4K6KPDTX7Y6BTAVCNFSM6AAAAAA4IUKMXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRVHEYTMNBYGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Closing as stale. In light of the Wallet Standard and the new web3.js, I think we'll probably not be accepting most new wallet adapters, and encourage teams to self-publish.


Traveling Salesman Problem to fix

After read books about Traveling Salesman Problem it is considered a Non-deterministic Polynomial Time Complete as it consider that salesman will back to start point. So your solution may be incomplete because you are not considering that salesman need to return to beginning.
Here is where I am checking this information: Cormen, Thomas H., ed. (2013) Algorithms Unlocked. The MIT Press
But in my mind it can also be a NP Time Complete algorithm without return to start point. I did a checkbox to include the return to beginning in distance count. I believe that you can improve your solution to be better suited to some computer science literature's.
Please, let me know if I am correct in my analysis

Hi Darthmall!
The algorithm can definitely be improved and changed for actual use, for the website however we tend to stick to the examples from the videos! Your point is valid for sure though!
P.S. you should join our community discord for questions and remarks you might have in the future!


website_sale_search_clear not working in 10c

As soon as we install website_sale_search_clear we receive a 500 error

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@lisandi Hi, I have the same issue as well and I believe the issue is related to the inherited shop method
https://github.com/it-projects-llc/website-addons/blob/f3d2ffee6fc612c7bd7398d763fd1c3aac5b1295/website_sale_search_clear/controllers.py#L8-L12
The method should have ppg as the parameter
i.e.
@http.route()
def shop(self, page=0, category=None, search='', ppg=False, **post):
	if category and search:
		category = None
	return super(WebsiteSale, self).shop(page, category, search, ppg, **post)

Fixed in #300 for version 10.0


Update the data before emitting the input and close events

Description
Fixes a datepicker problem occurring when manually typing the time.
Related Issues
Fixes #2667

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


[EXPLR]

Description
[replace this line with a clear and concise description of the Chainlink Explorer issue you are experiencing]
Basic Information
[replace this line with basic information about the issue you are experiencing, including but not limited to the name and version of your web browser and the value you are searching for]
Steps to Reproduce
[replace this line with detailed steps to reproduce the issue you are experiencing]
Additional Information
[replace this line with any additional information you would like to provide, such as screenshots illustrating the issue]

https://cryptotabbrowser.com/12467336


2D MPR Between Series/Sequences.

In conversations with Brazilian medical professors, we found that this type of analysis makes understanding certain studies easier to understand.

I'm still getting acquainted with OHIF and I need help. Currently, 2D MPR viewing is done in a single sequence. I would like to know if in OHIF I can start 2D MPR visualization between different sequences. If not currently possible, is it possible to implement such a feature via vtk.js or another tool?
An example that illustrates this feature is present in Horus where we select distinct sequences, click 'Enter' and the '2D MPR' visualization starts:
https://user-images.githubusercontent.com/43360593/137923884-bcc6b8b4-f5af-4140-a73e-3afc4b8b1ade.mp4
In OHIF, if I start the 2D MPR and select another sequence, the view is broken:
https://user-images.githubusercontent.com/43360593/137925355-ddfceb0f-3290-4266-91b8-d2f6349441a9.mp4

@e-farias Have you been able to solve this problem?

awesome！thanks for your share


README: fix unknown toggle-unmodified-files config

Fix unknown toggle-unmodified-files config.
The keybinding.toggle-unmodified-files is unknown config. actually keybinding.toggle-unchanged-file.

If dive continue to use keybinding.toggle-unmodified-files value, I'll change this pull request to following diff:
diff --git a/cmd/root.go b/cmd/root.go
index 01d0988..580484c 100644
--- a/cmd/root.go
+++ b/cmd/root.go
@@ -74,7 +74,7 @@ func initConfig() {
 	viper.SetDefault("keybinding.toggle-added-files", "ctrl+a")
 	viper.SetDefault("keybinding.toggle-removed-files", "ctrl+r")
 	viper.SetDefault("keybinding.toggle-modified-files", "ctrl+m")
-	viper.SetDefault("keybinding.toggle-unchanged-files", "ctrl+u")
+	viper.SetDefault("keybinding.toggle-unmodified-files", "ctrl+u")
 	viper.SetDefault("keybinding.page-up", "pgup")
 	viper.SetDefault("keybinding.page-down", "pgdn")

diff --git a/ui/filetreeview.go b/ui/filetreeview.go
index 8f42cd4..9681c62 100644
--- a/ui/filetreeview.go
+++ b/ui/filetreeview.go
@@ -97,7 +97,7 @@ func NewFileTreeView(name string, gui *gocui.Gui, tree *filetree.FileTree, refTr
 		log.Panicln(err)
 	}

-	treeView.keybindingToggleUnchanged, err = keybinding.ParseAll(viper.GetString("keybinding.toggle-unchanged-files"))
+	treeView.keybindingToggleUnchanged, err = keybinding.ParseAll(viper.GetString("keybinding.toggle-unmodified-files"))
 	if err != nil {
 		log.Panicln(err)
 	}

Good catch, and thanks for the PR. My preference would be to keep the keybinding.toggle-unmodified-files verbiage (though this would be a breaking change for folks configured 'properly').
Would you mind updating the PR with the diff you provided in the comments instead?

I'll merge this into a feature branch and sync the branch with master, then apply the patch in your comments above.


"Please upload an image" error message

follow these steps to reproduce:

upload image
click on change photo in modal
close file select dialogue box without selecting a new file
finish report back process

@mikefantini do you know if this is still a bug? thanks!


Fix: buffer overflow when the length of hostname more than 32 chars

fix #13

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