Adds a model format loop command

If you input some desired behavior and then run model for a loop on it will try to generate loop that solves the problem.

I think we should probably change this to format code or something.  Since changing selected text into code is not specific to iteration or looping.

I do think it would be good to provide some additional programming constructs; I think providing the context that the expected output is a loop helps the LLM to give a more targeted response. I'm not sure if we need to do all constructs, but conditional was one I was thinking would be good (switch is one kind of conditional too)

A general purpose code one could be good too, though I'm not sure it will do so well at that beyond basic syntax.

Here's a thought-what if we add both and try them out for a while, and if we discover that format loop and format code are roughly equivalent we could deprecate format loop? That way we can test them out before making a final decision there.

That said, I do think there's also value in providing some mechanism for users to customize their own prompts too, which I think is what you were hinting at. I don't think the two things are tied together though.

I would prefer to first merge a model convert code since I think this is relatively niche. GitHub copilot is really much better at this given the fact it can insert into the proper destinations and gain the context of your codebase, and you don't need to select text beforehand.  I think format code is ok since it is not too specific and we already have shell.
It's totally fine if you find format loop to be useful. I just think it is too specific to your setup to merge, since I don't think many people write the instructions down before they generate the code. I would prefer to encourage people to use the copilot integration. I know you said you don't use copilot, which is totally fair, but I think there are some open source alternatives that can be used instead.
It's possible that what we want to do is to change the static list into a talon capture, such that the capture is a logical OR of the prompts included within the static list or the user's special custom prompt list.

We discussed on the phone and I think we arrived at a good compromise:

move these prompts to a new section called "code generation"
put that towards the bottom of the file
use a different namespace "generate" to prefix the commands

This way it doesn't collide with the model format commands and makes IT fairly simple to see and experiment with the code generation ones.

Looks good thanks. If the underlying model changes affect this at all going forward let me know and we can discuss going forward in more depth about pinning  model versions


spelling error fix of install-thrift-linux.sh

spelling error fix of install-thrift-linux.sh

Codecov Report

Merging #4632 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4632      +/-   ##
==========================================
+ Coverage   40.35%   40.41%   +0.05%
==========================================
  Files        2512     2510       -2
  Lines       76555    76463      -92
  Branches    10424    10401      -23
==========================================
+ Hits        30897    30903       +6
+ Misses      42822    42725      -97
+ Partials     2836     2835       -1

Impacted Files
Coverage Δ

...pinpoint/rpc/ChannelWriteFailListenableFuture.java
42.85% <0%> (-28.58%)
:arrow_down:

...navercorp/pinpoint/rpc/common/SocketStateCode.java
82.92% <0%> (-2.44%)
:arrow_down:

...corp/pinpoint/rpc/stream/StreamChannelManager.java
70.68% <0%> (-1.73%)
:arrow_down:

...t/plugin/rabbitmq/client/RabbitMQClientPlugin.java
0% <0%> (ø)
:arrow_up:

...nt/interceptor/ChannelBasicPublishInterceptor.java
0% <0%> (ø)
:arrow_up:

...nt/interceptor/AMQCommandConstructInterceptor.java

...t/plugin/rabbitmq/client/aspect/ChannelAspect.java

...cluster/zookeeper/ZookeeperClusterDataManager.java
65.3% <0%> (+0.68%)
:arrow_up:

...pinpoint/profiler/monitor/DeadlockMonitorTask.java
19.76% <0%> (+1.16%)
:arrow_up:

...point/rpc/client/DefaultPinpointClientHandler.java
72.61% <0%> (+1.59%)
:arrow_up:

... and 3 more

Continue to review full report at Codecov.

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


Gentype / Bucklescript clean

I am publishing packages to npm to be consumed by TS users. Common file structure for this is to have js files and definitions/types alongside.
After bsc/gentype build is done I am running tsc to output index.js, index.gen.js and index.gen.d.ts for TS consumers
index.gen.d.ts       # tsc artifact
index.re
index.bs.js          # bsc artifact
index.gen.js         # tsc artifact
index.gen.js.map     # tsc artifact
index.gen.tsx        # gentype artifact

I can't just publish raw JS output from reason/tsc, because package depends on other reason packages. So bsb -make-world with dependency to my package should be called on consumer side... if clean is called it removes index.gen.js and the only way to get it back is to reinstall package from npm.
Can bucklescript be aware of what files are generated by gentype and remove only them? For example based on gentypeConfig.language setting (if it is set to "typescript" - only index.gen.tsx will be removed). Current behaviour is to remove all index.gen.{js,tsx,flow}
ping @bobzhang @cristianoc
Not sure where this issue should be opened, might be that Bucklescript is more correct place for it.

original and incorrect assumption about issue
Currently `bsb -clean-world` is removing genType generated files from `node_modules`, but `bsb -make-world` is not re-creating them. Should clean/build process be aligned in one of ways:

not cleaning node_modules genType generated files
bsb -make-world also generates types from node_modules

Second option is way trickier and hard to get it right? I will be happy with the first option.

@Coobaha the generated files in node_modules: how did they get there in the first place?

They are published alongside with reason source. Consumers are using them as TS modules published to npm. As I mentioned in more context part I cant just publish JS artifacts because of transitive reason dependencies that are fetched from npm too.

What about .bs.js artifacts: are they also published alongside? And what happens to them: are they removed on -clean-world and re-created on -make-world.
Just asking whether there is a distinction on how different kinds of artifacts are generated, so we can look into why.

Actually it is removing *.gen.js files (which i am generating before publishing with tsc)
before bsb -clean-world -make-world
index.re
index.bs.js
index.gen.js
index.gen.js.map
index.gen.tsx

after
index.re
index.bs.js
index.gen.js.map
index.gen.tsx

@Coobaha are .bs.js files never removed? Or are they removed and re-built?

@cristianoc they are removed on -clean-world, gentype files are recreated again but obviously index.bs.js is not there because it is generated outside of bsb context. Probably Bucklescript should remove files based on gentypeConfig.language setting. For example if it is set to typescript - only index.gen.tsx will be removed?

@Coobaha I'm still unclear why .gen.js files are generated, as it appears they are not produced by genType. Could you use another extension, just to unblock this?
And yes, bsb clean could be a bit more specific (it makes sense to create and issue on this in the bucklescript repo).

I've updated issue description to be more clear. I can also come up with repro repo if needed

Not sure if i can, will check tsc options

https://github.com/BuckleScript/bucklescript/issues/4417 create new issue in the bucklescript repo

tsc is not allowing this, the only option is to concatenate output to one file but it has drawbacks more details

Got it thanks.
I had no idea that ts generates .gen.js.


Travis-cargo not working with Rust 1.10 and cargo 0.11

Ever since Rust 1.10 went stable, travis-cargo doesn't update test coverage anymore on coveralls (no new builds are being recognized). Temporary workaround is to add a 1.9.0 target in .travis.yml which fixes the problem but it would be great if it could work out of the box with latest stable release. :)

I am having the same issue. It looks likes travis-cargo isn't calling kcov correctly. https://travis-ci.org/mattnenterprise/rust-imap/jobs/144881951#L805

Same issue 😄.

Related to #55.


Explicitly validate user args passed to transform

Comes out of discussion on #831 and https://github.com/ryan-williams/adam/pull/1. With the "Swiss Army Knife" nature of transform, there are a fair number of possibly conflicting ways that arguments can be passed. We should more explicitly validate the arguments passed.

Was this addressed in #1081?

No, it wasn't.

Closing as won't fix.


Power Platform checker fails with new Build Task update

Hello,
since the update for the BuildTasks we are facing an issue with Power Platform Checker.
It suddenly stopped working:

The task configuration wasn't changed and does not use custom endpoint although the error message states so.

@lar-mar This is ultimately a typo/finger twister:

typo: httts instead of https
To remain backwards compatible with the PS implementation, the checker task tries to determine which checker endpoint to use based on the region part of the environment url (e.g. crm, crm4, crm9 etc.). That envUrl can come either via the BuildTools.EnvironmentUrl pipeline variable but also as fallback, from the "server Url" property of the service connection.
We've since also rolled back to the PS-based PP-BT implementation, which was/is more tolerant to a pot. invalid url; see #144


Code Feedback

Code Feedback

Sometimes I see extra white lines (enters) between code, try to keep this consistent.
I like the way of multiple functions calling eachother to create the template, I see no global variables which is good.
I see good error handling
I'd suggest creating modules for these different functions, for example the genre function. That one creates the template which deserves it's own module in my opinion.
Add more comments to your code, this makes it easier to read for yourself and others aswell.

Thanks buddy! This issue is resolved.


Unable to use dwl tags

Using dwl 0.4
Patched the second one in this list https://github.com/djpohly/dwl/wiki/ipc
Patching output:
patching file Makefile
patching file config.def.h
Hunk #1 FAILED at 111.
1 out of 1 hunk FAILED -- saving rejects to file config.def.h.rej
patching file dwl.c
Hunk #3 succeeded at 176 (offset -5 lines).
Hunk #4 succeeded at 257 (offset -6 lines).
Hunk #5 succeeded at 318 (offset -7 lines).
Hunk #6 succeeded at 384 (offset -7 lines).
Hunk #7 succeeded at 734 (offset 27 lines).
Hunk #8 succeeded at 954 (offset 24 lines).
Hunk #9 succeeded at 1089 (offset 18 lines).
Hunk #10 succeeded at 1241 (offset 18 lines).
Hunk #11 FAILED at 2059.
Hunk #12 succeeded at 2471 (offset -25 lines).
Hunk #13 succeeded at 2613 (offset -25 lines).
1 out of 13 hunks FAILED -- saving rejects to file dwl.c.rej
patching file protocols/dwl-ipc-unstable-v1.xml
Then i get this: [error] dwl_status_manager_v2 not advertised

Hi. As it says there in the wiki, the patch you used doesn't work with waybar, only with dwl-bar. If you want to use waybar with dwl, I'd recommend getting the latest dwl from the git sources and applying the first patch in the list. As it says, the first one uses dwl-ipc-unstable-v2 which is supported by waybar, while v1 is not. I applied the v2 patch on the latest git sources (as of 18 July 2023) and it worked, but I think it might have had some areas where manual patching was necessary.

@theshatterstone Hiyya. I am using the latest git pull of the wlroots-next dwl branch, latest wlroots, the first patch on the list, and get the same message: "dwl_status_manager_v2 not advertised"
I did have to do some manual patching but was able to get it compiled. I'm new to dwl so maybe I've done something wrong.

@fictitiousexistence So when I was patching dwl, my main issues came from either using the wrong dwl (0.4 stable, instead of just using the main branch) or not getting the changes from my config.def.h copied to config.h. Config.def.h is the file that should get patched with the new configurations you have available after adding a patch. To ensure that, compare config.def.h (current default config), config.def.h.orig (the old config.def.h) and config.def.h.rej (any patches to config.def.h that were not done; if it just lists patches for dwl.c, then all the patches for config.def.h were done successfully)
So you say you've got it compiled. Does it work now?

@theshatterstone
With much embarrasment I've realized what I did lol.
I had 2 copies of dwl.
One I had working with gapps but when I tried the ipc patch I ran into issues.
I later git pulled a fresh copy to try the ipc patch, which compiled.
Then I relized something I forgot to do in the original dwl I had with gapps so I went back to that one and did the thing I forgot. It compiled! I thought I all was good but it didnt work.
I ended up comparing the 2 and finding what I did right / and wrong in each one and fixed it and got it working now :D
Thanks.

@fictitiousexistence No problem. I think it would be safe to close this issue now.

Seems like it. Patch works as supposed to- all human error aside :D

Im on the latest commit of dwl with the this ipc patch
I also have this error

@Xgames123 : maybe your issue is also related to https://github.com/Alexays/Waybar/issues/2371?


Allow custom escape

fixes #1377

Checklist:

[x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[x] Add or update relevant docs, in the docs folder and in code.
[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[x] Add .. versionchanged:: entries in any relevant code docs.
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.
[x] Check all left TODOs

[x] Make sure that the left Markup() calls do not overwrite custom escapes with HTML escapes
[x] if possible create yet some more test for some changes (see TODOs as well)

[x] add some more changed version documention, but IMO low prio
[x] add a test that uses files that have includes / extends templates that have different endings (configured to different auto escapern)

Hi guys,
thanks for your efforts, will work you comments in tomorrow or the days after tomorrow.
Actually PyCharm has Spell Check enabled but especially for grammar stuff it's not that good yet.
Probably I also have to change some settings as I guess I just missed some spell underlines 🤷🏻 🤦🏻
As I wrote in #1377, I am bit of (maybe not only a bit ;-) ) dyslexic, even in my native language (the one I probably share with @jugmac00).
So thanks for taking the effort in checking and correcting -> much appreciated!
Also is the first time for me that an PR in github actually got reviewed, so I also need to get started on this :)

@davidism is okay for your to take care of the conflict in docs/api.rst that was introduced through: #1391?

the moment when you worked 4hours to resolve a merge conflict and you realise that in the meanwhile the next PR was merge that causes the next merge conflict 😭

@ThiefMaster I fixed everything so far. Documentation is up to date, tests are as well. Currently no Merge Conflicts.
How likely is that you will give your ok for the PR? Because I rather would not to spend any more work into something that goes into the bin.
Also because this change touches code on so many places, that other PR most likely will introduce other Merge Conflicts.

Because I rather would not to spend any more work into something that goes into the bin.

Don't worry about that. If we believed this was something we don't want we'd have told you from the beginning.
However, this is a large and complex PR, and while I will have another look, I don't think I'm going to be the one that will take the final decision on it and merge it; I'll leave that up to @davidism once he has the time for it.
I wouldn't worry too much about merge conflicts - most of them can probably be resolved right before merging.

@davidism once you check the code, have a lock especially on the async stuff. I have no experience with async coding what so ever, so my changes are more like an educated guess.
I still tried to write some tests but not sure if I covered all the cases.
Maybe you also find a way make EvalContext known to the async Macros....

@davidism Did the rebase and combination as requested.
One thing: When are you planning to release 3.0?
Are you following SemVer?
Because if you do it would be good not only to deprecate Markup but directly make people aware of the functions that will return the correct Markdown class?
Otherwise there will be one braking change between 3.0 and 3.1.
My suggestion would be to create a small PR that only provides the functions to get the (then only hardcoded) Markdown and escape functions.
Is this understandable?
What do you thing?

We don't follow semver.
I don't understand what the breaking change is, the only thing this PR should be doing is adding customization capabilities, not changing existing behavior.

First of all. Sorry I missed that release. Big thing, updating all libraries at once. Congratulations 🎉

We don't follow semver.
Good to know.
I don't understand what the breaking change is, the only thing this PR should be doing is adding customization capabilities, not changing existing behavior.

Braking change is for all creators of custom extensions and people that use Markdown directly in normal Python code to define a string as safe.
If they combine it with custom escape it could lead to unexpected behaviour (i.e. when using the % operator).
Tried to explain that in the documentation of the PR as good as possible.

That's not a breaking change though, that use case will continue to work, but they'll need to update if they want to take advantage / make correct use of customization that this enables. That's what a good changelog message and docs are for.

@davidism I changed things as requested. If there are still any issues, let me know.

@davidism and @ThiefMaster will this ever be merged?

Yes, I do plan to eventually merge this. It is a huge set of changes, and I just have not been able to sit down and properly review it. I can't block the release of 3.1 on this, so I'm moving it to 3.2 for now.

@davidism just another ping. Anything I can do to support you on this MR?

@davidism And here the yearly ping again 😉 . Anything I could do to finally finally get this merged?

Happy 3rd birthday MR :-)
@davidism I know this is a huge MR, due to the way how autoescape is handled currently.
In the meanwhile I gained a lot more experience, also with async. I could review the MR again, rebase it and see if I am able to maybe reduce the number of changes lines.
But I would only invest this time if there are resources on pallets side to review and merge the MR. Otherwise I will check in a year again.
Feel free to reach out with tasks and questions related to this MR 🤗


CI was broken because of a missing directory

See:
https://salsa.debian.org/go-team/packages/golang-github-pkg-diff/-/jobs/1430397
and
https://salsa.debian.org/go-team/packages/golang-github-pkg-diff/-/jobs/1432360
I am not sure if this should applies to everyone, and I have also opened a MR on salsa: https://salsa.debian.org/go-team/ci/-/merge_requests/3

Hello @fauust !
I'm waiting to get back the CI infrastructure running and if that's do the trick I'll merge it right away.
Thanks!

Hello back!
As it turns out, while this 'fix' the pipeline it does not solve the underlying issue.
The /srv/gopath/src is created by pgt-gopath and therefore should exists. It's not the CI job to create it.
Cheers,


AddHeadersToRequest with Claims[sub] and Claims[roles]

Expected Behavior / New Feature
When pass this:
"AddHeadersToRequest": {
   "tenantId": "Claims[tenantId] > value",
    "caller": "Claims[sub] > value",
    "roles": "Claims[roles] > value"
}

with this token:
"sub": "8723c40a-0b57-4447-b1a5-d3c15f7ca9ea",
"typ": "Bearer",
"roles": ["Admin","User"]

Expect to have 3 header values.
Actual Behavior / Motivation for New Feature
  "tenantId": "Claims[tenantId] > value",

This works no problem. If I type typ it also works. if I type other claims from token it all works.
But when I use sub it says: Cannot find a claim for key: sub errors found in ResponderMiddleware.
If roles, the same: Cannot find a claim for key: roles errors found in ResponderMiddleware.
This they are all there in the token. And I can use most of the other claim names.
Is sub and roles somewhat reserved or ignored?
Steps to Reproduce the Problem

add:

"AddHeadersToRequest": {
  "tenantId": "Claims[tenantId] > value",
  "caller": "Claims[sub] > value"
}

"AuthenticationOptions": {
  "AuthenticationProviderKey": "myKey",
  "AllowedScopes": []
}

call API with valid bearer token.

I see now that JwtBearer settings in ASP .Net with the Jwt Schema change sub and roles to namespaces like this: {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier: 8723c40a-0b57-4447-b1a5-d3c15f7ca9ea}
so my sub I pass in is transformed to "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
To fix this I need to do:
var claimValues = claims.Where(c => c.Type == ClaimTypes.NameIdentifier).Select(c => c.Value).ToArray();
in the ClaimsParser if key is sub.
Or use:
"caller" : "Claims[http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier]

Or you use
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
in Startup and claims are back normal.

if the claim name is nameid, it is not getting forwarded. On other names it is working fine

@jnormen
Do you still see an issue or not? I don't!
I cannot accept it for development, but we can discuss it more...


Extra blank space in "No. #NUMERIC#" returning unexpected tokens from MosesTokenizer

To resolve the nltk/nltk_data#85, stripping the non-breaking prefixes would emulate the Perl chomp from the original Moses tokenizer.perl
This can be patched easily by replacing https://github.com/nltk/nltk/blob/develop/nltk/tokenize/moses.py#L244
# Initialize the language specific nonbreaking prefixes.
 self.NONBREAKING_PREFIXES = nonbreaking_prefixes.words(lang)

to
# Initialize the language specific nonbreaking prefixes.
 self.NONBREAKING_PREFIXES = [_nbp.strip() for _nbp in nonbreaking_prefixes.words(lang)]

This is good first bug to contribute to NLTK too =)

@alvations
I've requested a pull request with the changes you suggested. First time contributing to open source, so please let me know if I need to make any changes.

Resolved in #1802


Improve & fix Mono build

Fix C++ compile errors about pending variable renames after the Reference to RefCount change.
Fix C# compile errors due to the recent rename of EnablePlugin() and Build(), which are now underscore-prefixed in bindings.
Additional rename: godot_icall_Reference_Dtor to  godot_icall_RefCounted_Dtor.

Thanks!


docker compose make quick start hangs

After tried quick start, I met the followint error:
Status: Image is up to date for openwhisk/dockerskeleton:latest
host ip address: <IP_ADDRESS>
checking required ports ...
 ... OK
  ... preparing api-gateway configuration
pinging minio...
.Starting openwhisk_minio_1 ...
Starting openwhisk_minio_1 ... error

ERROR: for openwhisk_minio_1  Cannot start service minio: error while creating mount source path '/home/zjli/tmp/openwhisk/minio': mkdir /home/zjli/tmp/openwhisk/minio: permission denied

ERROR: for minio  Cannot start service minio: error while creating mount source path '/home/zjli/tmp/openwhisk/minio': mkdir /home/zjli/tmp/openwhisk/minio: permission denied
ERROR: Encountered errors while bringing up the project.
.....^CMakefile:204: recipe for target 'setup' failed
make: *** [setup] Interrupt

Then I created the directory  /home/zjli/tmp/openwhisk/minio manually.
After that, I got the problem the same as @rinswind .
latest: Pulling from openwhisk/dockerskeleton
Digest: sha256:85afe317d91b2fd97243812084b27e502dd2e6e001a187febd42af9ba61d03ce
Status: Image is up to date for openwhisk/dockerskeleton:latest
host ip address: <IP_ADDRESS>
checking required ports ...
 ... OK
  ... preparing api-gateway configuration
pinging minio...
.Recreating f917ca3a609c_openwhisk_minio_1 ...
Recreating f917ca3a609c_openwhisk_minio_1 ... done
...............................................................................................................................................................

Bellow is my environment:
Docker version 17.12.0-ce, build c97c6d6
Ubuntu 16.04.3 LTS

Originally posted by @axiqia in https://github.com/apache/incubator-openwhisk-devtools/issues/116#issuecomment-442045047

It looks like we need some error handling if mkdir ~/tmp/openwhisk/minio can't be created.

and to confirm - it's still happening? (wasn't able to reproduce myself off master)

It has been a month, so I'm not sure, I will try again tomorrow and then report.

sudo shouldn't be required - @zhululai any chance you have the logs without root --- did make fail in the same described here?

I didn't get the error message as described above, but make quick-start is hanging after Starting openwhisk_minio_1 is done.

I also got stucked after Starting openwhisk_minio_1 was done, with no error message!

Try make again - does it persist?

I have already solved this problem, my problem was caused by the version of docker.
DO NOT USE yum -y install docker, this version was too old!!! Use yum install docker-ce to install docker.

Bellow is my environment.
$ cat /etc/issue
Ubuntu 16.04.3 LTS \n \l

$ docker-compose --version
docker-compose version 1.22.0, build f46880fe

$ docker --version
Docker version 18.09.2, build 6247962

I  tried to update docker, but it didn't help.
$ make quick-start
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   134    0   134    0     0     91      0 --:--:--  0:00:01 --:--:--    91
100 14.3M    0 14.3M    0     0  1940k      0 --:--:--  0:00:07 --:--:-- 3593k
Unpacking tarball.
downloading the CLI tool ...
downloading cli for linux
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   626    0   626    0     0    455      0 --:--:--  0:00:01 --:--:--   455
100 3847k  100 3847k    0     0   612k      0  0:00:06  0:00:06 --:--:--  904k
pulling the docker images short list...
 OK
  ... preparing api-gateway configuration
pinging minio...
Starting openwhisk_minio_1 ... done
....................................................................................................................................................

Environment
incubator-openwhisk-devtools/docker-compose$ cat /etc/issue
Ubuntu 18.10 \n \l
incubator-openwhisk-devtools/docker-compose$ docker-compose --version
docker-compose version 1.23.2, build 1110ad01
incubator-openwhisk-devtools/docker-compose$ docker --version
Docker version 18.09.3, build 774a1f4

Error
incubator-openwhisk-devtools/docker-compose$ make quick-start
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   134    0   134    0     0    154      0 --:--:-- --:--:-- --:--:--   154
100 14.4M    0 14.4M    0     0  1429k      0 --:--:--  0:00:10 --:--:-- 1875k
Unpacking tarball.
downloading the CLI tool ...
downloading cli for linux
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   626    0   626    0     0    750      0 --:--:-- --:--:-- --:--:--   749
100 3847k  100 3847k    0     0   835k      0  0:00:04  0:00:04 --:--:-- 1537k
pulling the docker images short list...
Using default tag: latest
latest: Pulling from openwhisk/controller
Digest: sha256:b4bec4b65ac17ae157ef0ff2de7085493f400ade322e066d5f99f1d07b031a5f
Status: Image is up to date for openwhisk/controller:latest
Using default tag: latest
latest: Pulling from openwhisk/invoker
Digest: sha256:bdc6df912b2d2f642206b0f2a83d20e29256409598f3f8299df81abc8871c4cb
Status: Image is up to date for openwhisk/invoker:latest
Using default tag: latest
latest: Pulling from openwhisk/nodejs6action
Digest: sha256:e259aa02886ebb0bb7370bfa61e37d665c9e07d6677043d3635ce95e8a4d26bc
Status: Image is up to date for openwhisk/nodejs6action:latest
Using default tag: latest
latest: Pulling from openwhisk/dockerskeleton
Digest: sha256:60143b05544ccfffc2e38c2653ea3c5275b6cedd458887687b39ec67b9841c0c
Status: Image is up to date for openwhisk/dockerskeleton:latest
host ip address: <IP_ADDRESS>
checking required ports ...
 ... OK
  ... preparing api-gateway configuration
pinging minio...
 ... OK
openwhisk_minio_1 is up-to-date
2019/03/12 06:44:08 ERROR : Attempt 1/3 failed with 1 errors and: RequestError: send request failed
caused by: Head http://minio.docker:9000/api-gateway: dial tcp <IP_ADDRESS>:9000: connect: no route to host
2019/03/12 06:44:28 ERROR : Attempt 2/3 failed with 1 errors and: RequestError: send request failed
caused by: Head http://minio.docker:9000/api-gateway: dial tcp <IP_ADDRESS>:9000: connect: no route to host
2019/03/12 06:44:48 ERROR : Attempt 3/3 failed with 1 errors and: RequestError: send request failed
caused by: Head http://minio.docker:9000/api-gateway: dial tcp <IP_ADDRESS>:9000: connect: no route to host
2019/03/12 06:44:48 Failed to mkdir: RequestError: send request failed
caused by: Head http://minio.docker:9000/api-gateway: dial tcp <IP_ADDRESS>:9000: connect: no route to host
make: *** [Makefile:219: setup] Error 1

This issue still exist in my server.
output
host ip address: <IP_ADDRESS>
checking required ports ...
 ... OK
 setup ...
  ... preparing api-gateway configuration
pinging minio...
Starting openwhisk_minio_1 ... done
....................

Environment:
$ docker-compose -v
docker-compose version 1.24.0, build 0aa59064

$ docker -v
Docker version 18.09.6, build 481bc77
(python3)

ubuntu 16.04

minio log
$ cat  ~/tmp/openwhisk/setup.log
Attaching to openwhisk_minio_1
minio_1            |
minio_1            |  You are running an older version of Minio released 10 months ago
minio_1            |  Update: docker pull minio/minio:RELEASE.2019-05-23T00-29-34Z
minio_1            |
minio_1            |
minio_1            | ERROR Unable to initialize backend: Unable to write to the backend.
minio_1            |       > Please ensure Minio binary has write permissions for the backend.
openwhisk_minio_1 exited with code 1

So I change the directory permissions.
chmod 777 ~/tmp/openwhisk/minio
Then I run make quick-start again. And the Error message is similar to the first post in this issue.
ERROR: for openwhisk_db_1  Cannot start service db: error while creating mount source path '/home/sxue/tmp/openwhisk/couchdb': mkdir /home/sxue/tmp/openwhisk/couchdb: permission denieStarting openwhisk_kafka_1 ... error

ERROR: for openwhisk_kafka_1  Cannot start service kafka: error while creating mount source path '/home/sxue/tmp/openwhisk/kafka': mkdir /home/sxue/tmp/openwhisk/kafka: permission denied

ERROR: for db  Cannot start service db: error while creating mount source path '/home/sxue/tmp/openwhisk/couchdb': mkdir /home/sxue/tmp/openwhisk/couchdb: permission denied

ERROR: for kafka  Cannot start service kafka: error while creating mount source path '/home/sxue/tmp/openwhisk/kafka': mkdir /home/sxue/tmp/openwhisk/kafka: permission denied

Finally, I found out the reason for this situation.
Because my home directory is mounted on the NFS of head node, the root of my current node can not be authorized to be the root of the head node, so when writing the home directory, it is equivalent to anonymous users. Change the permissions of the relevant directories in makefile to 777, and everything will be fine.

... preparing api-gateway configuration
pinging minio...
.WARNING: The DOCKER_COMPOSE_HOST variable is not set. Defaulting to a blank string.
Creating openwhisk_minio_1 ... done
.............................................

I have the same issue
docker -v
Docker version 23.0.1, build a5ee5b1
docker-compose -v
docker-compose version 1.29.2, build 5becea4c
Ubuntu 22.04


Expansion handler added

Ideally to serve as a way to handle english and portuguese differently
EidosSystem now owns one, instantiates it with language (FWIW i imagine that here much code will be reused from Eng/PT, and only some will differ), and EidosSystem passes the ExpansionHandler to EidosActions to use for expansion.
Note -- added a "fixme" in the TestEidosActions class........ (line 149)
@gcgbarbosa FYI and reorganize anything you want as needed now or in the future!!
closes #487

So this is a refactoring and doesn't change any output and doesn't need to be merged for this impending release?

no -- doesn't change any output (at least I hope not!) and doesn't need to be merged in impending release (but can be!), it WILL facilitate some stuff that @gcgbarbosa is trying to do though, fwiw

@kwalcock I fixed the conflicts (and refactored a Geo thing's name  to me more scalarific) @vikas95 fyi

@kwalcock -- i have a bugfix/improvement I want to merge in, but i need to merge this one first... any ideas on timeline?

How about now?

@vikas95 does have a backlog of other variable names to change as well.


French translation

@zquestz, @checksum0 and I did a number of fixes and formatting changes to his translation on this branch. I got a quick language review but am waiting for a more thorough one within the next day or so.
Sorry the commit history is dirty. Especially I'm not sure what happened with modify2. If it is important, I can work to get rid of that.

This ready to merge? Have we had one more french speaker check the translation?

Looks good. My one issue is with the term "Quickstart". Would "Démarrage rapide" be a better fit than "Bien commencer"?

Looks good. My one issue is with the term "Quickstart". Would "Démarrage rapide" be a better fit than "Bien commencer"?

Hey, it has already been changed a few commit later.

This ready to go?

It's ready.


No suggestions for TypedDict value with Union[Literal, None] type annotation

Environment data

Language Server version: v2023.7.30
OS and version: XXX
Python version (& distribution if applicable, e.g. Anaconda): XXX

Code Snippet

from typing import TypedDict, Literal

class DataA(TypedDict):
    name: Literal["a", "b"] | None

data_a: DataA = {
    "name": "" # no suggestions when pressing ctrl+space
}

recording.webm

This issue has been fixed in prerelease version 2023.8.51, which we've just released. You can find the changelog here: CHANGELOG.md


added support for multiple Future Implementation

We are using the library in a Finagle context and I want to manage only one kind of Future at time, so I've added support to multiple Future implementations from the user side.
I.e. you can use Twitter Futures:
https://github.com/unicredit/ReactiveAerospike/blob/master/src/test/scala/eu/unicredit/reactive_aerospike/TwitterFactory.scala

Thanks for the PR! Before giving into to code: would it also be possible to convert the returned scala future to a twitter future?

This implementation enable you to use the choosen future at compile time.
I'll try to add a test to let you check how it works.
If you need to modify your future types at runtime you need to convert them manually or through something like Bijection...
https://github.com/twitter/bijection/tree/develop/bijection-util/src/main/scala/com/twitter/bijection/twitter_util

I added a basic example of the usage of the library with a different Future type,
unfortunatelly after this integration the test:
PingStatusObserver
should disable server on status != 200
fail, and I cannot argue why...

I'm a bit unsure and hesitant regarding these changes, especially about the implementation of ScalaFuture, and there are quite some api changes.
What do you think about the following: solrs adds support for twitter future in that it provides an implicit conversion from scala future to twitter future, so that a twitter future user could do either
import TwitterSupport._
val twitter: com.twitter.util.Future[QueryResponse] = solr.query(query)

or
import TwitterSupport._
val twitter: com.twitter.util.Future[QueryResponse] = solr.query(query).toTwitter

The implementation would look like this:
object TwitterSupport {

  import scala.concurrent.{ Future => ScalaFuture, ExecutionContext }
  import com.twitter.util.{ Future => TwitterFuture, Promise => TwitterPromise }

  implicit def scalaFutureToTwitter[A](f: ScalaFuture[A]): TwitterFuture[A] = {
    val p = new TwitterPromise[A]()
    f.onComplete {
      case Success(value) => p.setValue(value)
      case Failure(exception) => p.setException(exception)
    }(sameThreadExecutionContext)
    p
  }

  /**
   * Allows to use `scalaFuture.toTwitter`, if preferred.
   */
  implicit class ScalaFuture2TwitterT[A](f: ScalaFuture[A]) {
    def toTwitter: TwitterFuture[A] = scalaFutureToTwitter(f)
  }

  // Runs in the same thread as the caller of execute(), in our case this is desired
  private val sameThreadExecutionContext = new ExecutionContext {
    def reportFailure(t: Throwable) { t.printStackTrace() }
    def execute(runnable: Runnable) {runnable.run()}
  }

}

The point with your implementation is that, exactly after the execution within the scala.concurrent.Future and ExecutionContext of the query of your library, the Future is converted to a Twitter one.
The idea is that I'm using your library within a Finagle Microservice and I want to manage no more than one ThreadPool(or ExecutionContext if you like) type in the entire application.
With my implementation I inject at compile time the type of futures (and ExecutionContext) the library itself will use, and so I've control also over the ThreadPool used inside.

Ok, I understand that you don't want to manage the currently used global execution context.
I'd say that we should be able to get rid of all occurrences of real execution contexts. Everything that right now runs with a "real" execution context could also be run with a same-thread-execution-context (instead of e.g. scala's global one), because there's nothing done that needs to be executed in a separate thread. In consequence no thread pool would have to be managed. Would this improve the situation for you?
I've just pushed this to the "same-thread-execution" branch, let me know what you think.

Yes, I mean that I want to manage myself on the library "user land" witch kind(read also type) of ExecutionContext is used in the whole procedure call tree of my program.
In consequence if I choose to have "a single threaded execution" I want to be able to force it with a simple configuration in the client side code.
You are the original author, please take your time to choose how you want to manage that! ;-)

Andrea, I'd like to add support for finagle / twitter futures, I'll build upon your implementation but perhaps change some things. Comments may follow inline...

I'm working a bit on refactoring and keeping as standalone module the Future module itself,
it will require some days...

please check this implementation that looks better, but I'm not really sure about the retries policies was intended to use

Hi Andreas, thanx for the update, unfortunately I could not look into this so far, I'll still need some time (we're close to project launch and have a tight schedule...). Cheers!

Thanks for the update!
I'm not in a hurry for it, take your time and thanks in advance!

Hi @andreaTP, I picked this up again :-) I pushed a branch that should be fine, at least tests are green :-) What do you think, would this work for you?

Iy looks good to me!!!
Great work! Thanks for the effort!

Cool! I still need to document this and check some issues that travis reported, then I'll merge it.


Update test for parsing options in copyFromLocal and copyToLocal

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/1967/
Test PASSed.


Removing Helm release (the basic one) manually leads to HelmRelease stuck in "upgrade error" instead of re-installing

Describe the bug
After installing a HelmRelease (flux2), if we remove the corresponding "Helm" release (plain helm), flux2 seems to get stuck trying to upgrade a non-existing release.
Message
Helm upgrade failed for release my-ns/my-helmrel with chart<EMAIL_ADDRESS>"my-helmrel" has no deployed releases Last Helm logs: 2024-01-27T15:32:03.716328505Z: preparing upgrade for my-helmrel

Steps to reproduce
Deploy this HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: my-helmrel
  namespace: my-ns
spec:
  chart:
    spec:
      chart: ./lib/helm/my-chart
      reconcileStrategy: ChartVersion
      sourceRef:
        kind: GitRepository
        name: my-git-repo
        namespace: flux-system
      version: '*'
  install:
    remediation:
      retries: 3
  interval: 5m
  rollback:
    cleanupOnFail: true
  upgrade:
    disableWait: true
    remediation:
      remediateLastFailure: false
      retries: 3
      strategy: rollback
values:
   (...)

Wait for flux to finish installing the corresponding Helm release (plain)
Remove the "my-helmrel" Helm release (the base one, not the HelmRelease)
Expected behavior
HelmRelease controller should detect the release is no longer installed, and install (instead of continuing to try to upgrade)
Screenshots and recordings
No response
OS / Distro
N/A
Flux version
N/A
Flux check
flux check
► checking prerequisites
✔ Kubernetes 1.28.2-eks-28c5e82 >=1.26.0-0
► checking version in cluster
✔ distribution: flux-2.2.2
✔ bootstrapped: false
► checking controllers
✔ helm-controller: deployment ready
► ghcr.io/fluxcd/helm-controller:v0.37.2
✔ image-automation-controller: deployment ready
► ghcr.io/fluxcd/image-automation-controller:v0.37.0
✔ image-reflector-controller: deployment ready
► ghcr.io/fluxcd/image-reflector-controller:v0.31.1
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v1.2.1
✔ notification-controller: deployment ready
► ghcr.io/fluxcd/notification-controller:v1.2.3
✔ source-controller: deployment ready
► ghcr.io/fluxcd/source-controller:v1.2.3
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta3
✔ buckets.source.toolkit.fluxcd.io/v1beta2
✔ gitrepositories.source.toolkit.fluxcd.io/v1
✔ helmcharts.source.toolkit.fluxcd.io/v1beta2
✔ helmreleases.helm.toolkit.fluxcd.io/v2beta2
✔ helmrepositories.source.toolkit.fluxcd.io/v1beta2
✔ imagepolicies.image.toolkit.fluxcd.io/v1beta2
✔ imagerepositories.image.toolkit.fluxcd.io/v1beta2
✔ imageupdateautomations.image.toolkit.fluxcd.io/v1beta1
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta3
✔ receivers.notification.toolkit.fluxcd.io/v1
✔ all checks passed
Git provider
N/A
Container Registry provider
N/A
Additional context
{"level":"info","ts":"2024-01-27T16:02:04.197Z","msg":"HelmChart/flux-system/my-ns-my-helmrel with SourceRef 'GitRepository/flux-system/my-chart-resource' is in-sync","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"my-helmrel","namespace":"my-ns"},"namespace":"my-ns","name":"my-helmrel","reconcileID":"4e841bcf-5caf-40df-bef5-4ba060a45b6f"}
{"level":"info","ts":"2024-01-27T16:02:04.376Z","msg":"release not managed by controller: found existing release in storage","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"my-helmrel","namespace":"my-ns"},"namespace":"my-ns","name":"my-helmrel","reconcileID":"4e841bcf-5caf-40df-bef5-4ba060a45b6f"}
{"level":"info","ts":"2024-01-27T16:02:04.418Z","msg":"running 'upgrade' action with timeout of 5m0s","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"my-helmrel","namespace":"my-ns"},"namespace":"my-ns","name":"my-helmrel","reconcileID":"4e841bcf-5caf-40df-bef5-4ba060a45b6f"}
{"level":"error","ts":"2024-01-27T16:02:04.541Z","msg":"Reconciler error","controller":"helmrelease","controllerGroup":"helm.toolkit.fluxcd.io","controllerKind":"HelmRelease","HelmRelease":{"name":"my-helmrel","namespace":"my-ns"},"namespace":"my-ns","name":"my-helmrel","reconcileID":"4e841bcf-5caf-40df-bef5-4ba060a45b6f","error":"\"my-helmrel\" has no deployed releases"}

Code of Conduct

[X] I agree to follow this project's Code of Conduct

We didn't upgrade to 2.2.3 (we are using the pre-release patch hat includes helm 3.14) yet.

So it should work.
You should either have an upgrade if there is a previous release or a new install action.  I tested with helm-controller v0.37.4.
If you still have the issue, please provide a reproducible example of your deletion steps.


[REVIEW] Added LOG-LEVELs, Added ARCH Flag for CPU Worker Creation

Suggest to remove the --no-nanny where we aren't debugging to handle restarting / failed tasks more cleanly.

Our support for --no-nanny on GPUs is quite limited (e.g.) if something goes wrong, it will go wrong again, and again, ..., and debugging it won't be faster. I would say if a worker fails, it shouldn't try to restart.

I honestly feel like we need more infrastructure and error-handling in python before I feel comfortable adding the nanny back.


Exclude other search types when query contains is: or doc: or app:, etc

We should adapt the Algolia searchFunction to check for these patterns in the query and selectively disable/clear/hide/whatever other search result boxes.

@zeke started in 351632955ea5cd4cc1c82f72244acc92a88dd243


Can't enter non-numeric SIP addresses.

The input field prior to the '@' doesn't accept non-numeric values, while there are indeed non numeric addresses.
For example<EMAIL_ADDRESS>can not be dialed.

Hmm, true. But the primary use case (for me) is dialing PSTN numbers. Any idea how to permit what you want without making that inconvenient?

I suppose I could add a toggle, but it's kind of ugly...

How about making it a simple text field so that the normal keyboard would pop up?
And about making it inconvenient to type in normal phone numbers: Why not create your own in-app numeric keyboard?

And about making it inconvenient to type in normal phone numbers: Why not create your own in-app numeric keyboard?

Because this is even uglier than having a toggle? I'm a programmer, not UI designer.

Because this is even uglier than having a toggle?

Why do you think that? There's nothing wrong with an in-app numeric keyboard.

I'm a programmer, not UI designer.

Well, design-wise I'm imagining the number keys to have no background nor border. It would look like having the numbers directly on the background.
I'm no Android programmer, but I assume it should be possible to create a simple button with no background nor border? It would be a very simplistic design.
Unless you don't want to. Those are just suggestions.

I do want to support this functionality (since it is perfectly valid to request and clearly useful), but I don't want to do this in a way that is ugly, and I have no real idea how to implement this in a non-ugly way... maybe the dialer can be embedded somehow?

and I have no real idea how to implement this in a non-ugly way... maybe the dialer can be embedded somehow?

Maybe I wasn't clear enough. My suggestion was to have the in-app dialer right under the address input.
Imagine having simple buttons for each key, but simply removing the buttons' borders and backgrounds. That way it would look like the keys are directly on the background. It would be a very simple design.
You'd have your input at the top, and simply the dialer right below it:
|---------------|
|   ====@====   |
|   1   2   3   |
|   4   5   6   |
|   7   8   9   |
|   *   0   #   |
| [call button] |
|---------------|

I'd also suggest to move the call button all the way down.
And the reason I am putting emphasis on removing the borders and background is this:
| [ 1 ] [ 2 ] [ 3 ] |    ->    |   1   2   3   |

It looks a lot cleaner that way.

Implemented using an option.


Date queries

Feedback:

Hello,
Using {"hash":null, "update":ISODate("2015-12-12 00:00:00")}
I’ve got the error "Syntax error on selector: Unexpected token I"
Is it possible to query date with mongoclient ?
Regards,
Denis.

It's absolutely possible to query dates in mongoclient. You can simply use strings for this purpose. Have a look at FAQ section of wiki.


Corporate CSP preventing the use of "eval()"

Due to corporate CSP, eval() is forbidden :(
eval() is used in createStore()
Current
Object.values(drivers).forEach((driver) => {
    // bind reducer to store definition
    if (driver.getReducer) {
      const { reducer, path } = driver.getReducer() // eslint-disable-line no-unused-vars
      eval(`definitionWithDrivers${path.length > 0 ? '.' : ''}${path}=reducer`) // eslint-disable-line no-eval
    }

    // add enhancer
    if (driver.getEnhancer) driversEnhancers.push(driver.getEnhancer())

    // add init
    if (driver.init) driversInits.push(driver.init)
  })

Is it possible to change it this way :
    // bind reducer to store definition
    if (driver.getReducer) {
      const { reducer, path } = driver.getReducer()
      if (path.length > 0) {
        definitionWithDrivers[path] = reducer
      }
    }

As I understand it, we want to have a path for a driver's reducers. Is there any reason to use eval() here?

There is not, if this pass tests I would agree to merge it, feel free to open a PR :)

Ok, I will :)


Adding support for optional types

This is a first-cut implementation for issue #123, adding support for
the following optional types:
com.google.common.base.Optional
java.util.Optional
java.util.OptionalDouble
java.util.OptionalInt
java.util.OptionalLong
Regression tests have been added to cover various combinations of features.
This is based on https://github.com/rharter/auto-value-gson/pull/148 by
Alejandro J. C De Baca acdebaca@github and fixes merge conflicts.

@kaibolay Thanks for doing this. I recall there being one change that Ryan and I discussed in the PR that would be necessary to get this PR merged regarding how to default nullable Optionals. I'll take a look.


fix: change node requirement to say 14.x

So it matches what's on Vercel for them to apply the correct Node version automatically.

More info: https://vercel.com/docs/runtimes#official-runtimes/node-js/node-js-version
In particular,

Defining the node property inside engines
of a package.json file will override the selection made in the Project Settings and print a Build Step warning if the version does not match.

Screwed up the Docker build stuff with that change because the image wasn't pinned to a specific Node version 😅
The error: error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "14.x". Got "17.5.0"

@lucaslcode Do you mind re-approving this ^^


Allow synthesis of Codable for weak/unowned vars

What's in this pull request?
Allows non-strong (i.e. weak/unowned/unmanaged) vars to participate in Codable synthesis.
The type of non-strong properties is wrapped in a ReferenceStorageType, which does not conform to Codable. This needs to be unwrapped so the inner reference type can be considered for Codable conformance.

@swift-ci Please test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 14cec767647f70b46ad8427dbe13ad419170aa91
Test requested by - @itaiferber

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 14cec767647f70b46ad8427dbe13ad419170aa91
Test requested by - @itaiferber

Whoops, typo.

@swift-ci Please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 14cec767647f70b46ad8427dbe13ad419170aa91
Test requested by - @itaiferber

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 14cec767647f70b46ad8427dbe13ad419170aa91
Test requested by - @itaiferber

@swift-ci Please test macOS

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - dc11beb9232862b81184eaaabcb3f340b9092f72
Test requested by - @itaiferber

@bitjammer Looks like the changes you made to test/decl/protocol/conforms/fixit_stub_editor.swift in 9a17226d263 still doesn't fix the issue I was seeing earlier with this file (this has been problematic for #10253), and are causing a failure here (and in other PRs). Do you mind looking into this when you get the chance please?
CC @nkcsgexi

@jrose-apple has disabled the test entirely and I'll investigate about re-enabling it. This test should not block your validation now.

@nkcsgexi Excellent, thanks!

Adding some unit tests for this in the meantime.

Please don't let 4256a90 creep into your final merge. :-)

@jrose-apple Don't worry — some refactoring going on here locally; that was pushed by mistake. It'll get removed.

Closing in favor of #10321 (some rebasing work done on a different branch)


Straight upgrades org-mode on doom emacs to 9.7 version breaking A LOT of things

What's wrong
Everything is going south (many many more instances). It seems to point to org-mode 9.7 that is being installed by straight.el by default - it's a bleeding edge version.
Why isn't straight using stable branch? Is this a doom-related issue or does straight control this behavior?
Directions to reproduce
On doom emacs at least default installation process installs org-version 9.7
git clone --depth 1 https://github.com/doomemacs/doomemacs ~/.config/emacs
~/.config/emacs/bin/doom install

Version information

Emacs version: Doom Emacs - GNU Emacs 29.1
Operating system: Arch - EndeavourOS

For some context, the latest dev Org version brings up a number of inliners. So, stale .elc files may be especially problematic.

Thank you for fast response. You may be right, I found some suggestions to run doom build after updating emacs, which I believe is the command responsible for updating .elc files.

@danielkrajnik
Please see:
https://github.com/radian-software/straight.el#lockfile-management
Doom also modifies straight.el with it's own pinning mechanism.
I can't offer any support with that because I don't use Doom.

Why isn't straight using stable branch?

Which branch would you like it to use in Org's repository?

For some context, the latest dev Org version brings up a number of inliners. So, stale .elc files may be especially problematic.

In particular, I think that org-element-property might be the cause here. It was inlined in the past and its inliner expansion has changed. So, after Org upgrade, all the packages using org-element-property must be re-compiled because the inliner embedeed the old definition into their .elc files.

For users, the easiest solution would be clearing straight/build directory and re-compiling everything.

Thank you both, that's really helpful.

org-element-property might be the cause here

That's correct, thank you.

Which branch would you like it to use in Org's repository?

I believe org-mode has main branch, but you are right that this probably needs to fit with doom-emacs overall design. I will try to go back to doom and see what other solutions are proposed. Sorry for the trouble, it's many moving parts and hard to tell which one to follow.

I brought this issue up on https://yhetil.org/emacs-devel/8735112ttw.fsf@localhost/T/#u as the real problem is likely on Emacs side, similar to stale macro expansion Org suffered from in the past.

I brought this issue up on https://yhetil.org/emacs-devel/8735112ttw.fsf@localhost/T/#u as the real problem is likely on Emacs side, similar to stale macro expansion Org suffered from in the past.

I'm not sure if package.el handles that sort of thing when computing transactions or not.
Rebuilding dependencies before their dependents would do the trick.

If you don't need bleeding edge org-mode is there a way of telling straight.el just to use org-mode which is part of the Emacs build and stop any other package calling in another version from ELPA etc?
Although Doom et al might still be a problem as orgmode.org says
The Emacs starter kits Doom, Spacemacs and Scimax come with a curated set of packages and configurations that aim to enhance Org mode (and Emacs more generally) for particular use cases. They include Org along with integrations

If you don't need bleeding edge org-mode is there a way of telling straight.el just to use org-mode which is part of the Emacs build

See the straight-ignored-dependencies variable.

One user reported the same problem in Matrix. We got a little bit more detailed backtrace. The problem is gone once we run eval-defun on org-roam-db-insert-link. So, it is something clearly related to compilation.
However, removing straight/build directory and re-compiling (using doom sync) did not resolve the issue for the user.
So, there might be something more complex going on.
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  org-roam-db-insert-link((link (:standard-properties [573 700 nil nil 0 nil nil nil nil nil nil nil nil nil nil nil nil nil] :type "https" :path "//upload.wikimedia.org/wikipedia/commons/thumb/7/7..." :format plain :raw-link "https://upload.wikimedia.org/wikipedia/commons/thu..." :application nil :search-option nil)))
  org-roam-db-map-links((org-roam-db-insert-link))
  org-roam-db-update-file("/home/user/org/roam/20220916191431-xen_hypervisor....")
  eval((org-roam-db-update-file "/home/user/org/roam/20220916191431-xen_hypervisor....") t)
  eval-expression((org-roam-db-update-file "/home/user/org/roam/20220916191431-xen_hypervisor....") nil nil 127)
  funcall-interactively(eval-expression (org-roam-db-update-file "/home/user/org/roam/20220916191431-xen_hypervisor....") nil nil 127)
  call-interactively(eval-expression record nil)
  command-execute(eval-expression record)
  execute-extended-command(nil "eval-expression" nil)
  funcall-interactively(execute-extended-command nil "eval-expression" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

One user reported the same problem in Matrix. We got a little bit more detailed backtrace. The problem is gone once we run eval-defun on org-roam-db-insert-link. So, it is something clearly related to compilation.
However, removing straight/build directory and re-compiling (using doom sync) did not resolve the issue for the user. So, there might be something more complex going on.
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  org-roam-db-insert-link((link (:standard-properties [573 700 nil nil 0 nil nil nil nil nil nil nil nil nil nil nil nil nil] :type "https" :path "//upload.wikimedia.org/wikipedia/commons/thumb/7/7..." :format plain :raw-link "https://upload.wikimedia.org/wikipedia/commons/thu..." :application nil :search-option nil)))
  org-roam-db-map-links((org-roam-db-insert-link))
  org-roam-db-update-file("/home/user/org/roam/20220916191431-xen_hypervisor....")
  eval((org-roam-db-update-file "/home/user/org/roam/20220916191431-xen_hypervisor....") t)
  eval-expression((org-roam-db-update-file "/home/user/org/roam/20220916191431-xen_hypervisor....") nil nil 127)
  funcall-interactively(eval-expression (org-roam-db-update-file "/home/user/org/roam/20220916191431-xen_hypervisor....") nil nil 127)
  call-interactively(eval-expression record nil)
  command-execute(eval-expression record)
  execute-extended-command(nil "eval-expression" nil)
  funcall-interactively(execute-extended-command nil "eval-expression" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Users are apparently seeing the same issue sans straight.el:
https://www.reddit.com/r/emacs/comments/15jyzz7/strange_orgroam_bug_with_links_and_more/

Been running Doom for a few weeks now and loving it. I'm now trying to build a more organized note-taking system with org and org-roam.
I recently started getting the following error message with some of my org files on startup:
Error (org-roam): Failed to process ~/org/example_org_file.org with error Wrong type argument: integer-or-marker-p, nil, skipping...
It only happens on some of my files and I really don't know why. One thing that I realized triggers the error is including URLs; deleting all URLS fixed a few of my files. But two remain. One is just a few lines of text. The other is my main index / table of contents.
I upgraded my system today (Macbook Pro M1), so this may have caused the issue somehow, as it wasn't present even this morning. I'm using the emacs package emacs-macm which upgraded to 29.2 yesterday. I thought that this may have caused it, because I know that Doom doesn't officially support 29.2. But I un-installed and re-installed 28.2 via emacs-plus, and the error persists.
Can anyone offer any help? I'm happy to provide more info.

Nicholas Vollmer @.***> writes:

Users are apparently seeing the same issue sans straight.el:
https://www.reddit.com/r/emacs/comments/15jyzz7/strange_orgroam_bug_with_links_and_more/

That's on doom, which uses straight.el.
However, I am not able to reproduce the problem on fresh Doom install.
(with Emacs master and also with Emacs 28).
Maybe people also need to clean eln cache, not just straight/build...
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Ihor Radchenko @.***> writes:

Nicholas Vollmer @.***> writes:

Users are apparently seeing the same issue sans straight.el:

https://www.reddit.com/r/emacs/comments/15jyzz7/strange_orgroam_bug_with_links_and_more/
That's on doom, which uses straight.el.

Apologies. I misread the following:

I thought that this may have caused it, because I know that
Doom doesn't officially support 29.2. But I un-installed...

As them uninstalling Doom.
Deleted the comment after I re-read their post.

However, I am not able to reproduce the problem on fresh Doom
install.
(with Emacs master and also with Emacs 28).
Maybe people also need to clean eln cache, not just
straight/build...

It's hard to say without a solid reproduction case.
Users often try many different "solutions" (e.g. deleting build
and/or repo directories, re-building everything, downgrading Emacs
in this case, etc) all at once.

An update, related to https://github.com/ichernyshovvv/org-timeblock/issues/11
I was able to avoid a similar error by using package-vc-install, but not straight. May it be that straight is using built-in version of Org when compiling a package?

An update, related to https://github.com/ichernyshovvv/org-timeblock/issues/11
I was able to avoid a similar error by using package-vc-install, but not
straight. May it be that straight is using built-in version of Org when
compiling a package?

Again, anyone running into these issues should try their best to come up with a solid reproduction case (straight-bug-report can help with that).
It's a little hard to test when the repro involves someone's personal org-roam database, or no lack clear, step-by-step instructions.
The load-path should be set so that straight's $BUILD directory is added recursively.
See the following test output:

Test Case
(straight-bug-report
  :pre-bootstrap
  :post-bootstrap
  (straight-use-package 'org)
  (with-current-buffer (get-buffer-create straight-byte-compilation-buffer)
    (print (buffer-substring-no-properties (point-min) (point-max)))))

Test run at: 2023-08-07 12:52:13
system-type: gnu/linux
straight-version: prerelease (HEAD -> develop, origin/develop, test/compile) 325f2ca 2023-08-01
emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-07-25

Output
Bootstrapping straight.el...
Bootstrapping straight.el...done
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...done
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...done
Looking for emacsmirror-mirror recipe → Cloning el-get...
Looking for emacsmirror-mirror recipe → Cloning el-get...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done

Test run with version: prerelease (HEAD -> develop, origin/develop) 325f2ca 2023-08-01
Cloning org...
Cloning org...done
Building org...
Building org...done

"
$ /usr/bin/emacs -Q -L /tmp/straight.el-test-d3MqE5/straight/build/straight/ --batch --eval \\
 \"(let ((default-directory \\\"/tmp/straight.el-test-d3MqE5/straight/build/\\\"))
  (normal-top-level-add-subdirs-to-load-path)
  (byte-recompile-directory \\\"/tmp/straight.el-test-d3MqE5/straight/build/straight/\\\" 0 'force))\"
Checking /tmp/straight.el-test-d3MqE5/straight/build/straight/...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/straight/straight-autoloads.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/straight/straight-ert-print-hack.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/straight/straight-x.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/straight/straight.el...
Done (Total of 3 files compiled, 1 skipped)
Loading /tmp/straight.el-test-d3MqE5/straight/repos/org/lisp/org-compat.el (source)...
Loading /tmp/straight.el-test-d3MqE5/straight/repos/org/mk/org-fixup.el (source)...
  INFO     Scraping files for loaddefs...
  INFO     Scraping files for loaddefs...93%
  INFO     Scraping files for loaddefs...done
  GEN      org-loaddefs.el
File mode specification error: (file-missing Cannot open load file No such file or directory org-element-ast)

Error: file-missing (\"Cannot open load file\" \"No such file or directory\" \"org-element-ast\")
  mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode 0x18ceb492dfae857f>))
  debug-early-backtrace()
  debug-early(error (file-missing \"Cannot open load file\" \"No such file or directory\" \"org-element-ast\"))
  require(org-element-ast)
  (closure (org-fold-core-style ffap-url-regexp org-ts-regexp0 t) (epom &rest body) \"Move to buffer and point of EPOM for the duration of BODY.\\nEPOM is an element, point, or marker.\" (require 'org-element-ast) (let ((mepom (make-symbol (concat \"--\" (symbol-name 'mepom))))) (list 'let (list (list mepom epom)) (list 'save-excursion (list 'cond (list (list 'markerp mepom) (list 'set-buffer (list 'marker-buffer mepom))) (list (list 'numberp mepom)) (list t (list 'when (list 'org-element-property ':buffer mepom) (list 'set-buffer (list 'org-element-property ':buffer mepom))) (list 'setq mepom (list 'org-element-property ':begin mepom)))) (cons 'org-with-wide-buffer (cons (list 'goto-char (cons 'or (cons mepom '((point))))) body))))))(1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\")))
  macroexpand-1((org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\"))) nil)
  macroexp-macroexpand((org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\"))) nil)
  macroexp--expand-all((org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\"))))
  macroexp--all-forms((save-current-buffer (set-buffer (find-file-noselect \"../lisp/org.el\")) (org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\")))) 1)
  macroexp--expand-all((with-current-buffer (find-file-noselect \"../lisp/org.el\") (org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\")))))
  macroexp--all-forms((lambda (&rest _) (with-current-buffer (find-file-noselect \"../lisp/org.el\") (org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\"))))) 2)
  macroexp--expand-all((lambda (&rest _) (with-current-buffer (find-file-noselect \"../lisp/org.el\") (org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\"))))))
  macroexpand-all((lambda (&rest _) (with-current-buffer (find-file-noselect \"../lisp/org.el\") (org-with-point-at 1 (if (re-search-forward \"Version: +\\\\([0-9.]+\\\\)\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \"\\\\.\") 0 2) \".\") (error \"Missing \\\"Version\\\" keyword in \\\"org.el\\\"\"))))))
  org-macro--set-templates(((\"kbd\" . \"(eval (org-texinfo-kbd-macro $1))\") (\"version\" . \"(eval (with-current-buffer (find-file-noselect \\\"../lisp/org.el\\\") (org-with-point-at 1 (if (re-search-forward \\\"Version: +\\\\\\\\([0-9.]+\\\\\\\\)\\\" nil t) (mapconcat #'identity (cl-subseq (split-string (match-string-no-properties 1) \\\"\\\\\\\\.\\\") 0 2) \\\".\\\") (error \\\"Missing \\\\\\\"Version\\\\\\\" keyword in \\\\\\\"org.el\\\\\\\"\\\")))))\") (\"var\" . \"@@texinfo:@var{@@$1Cannot open load file: No such file or directory, org-element-ast
@@texinfo:}@@\") (\"cite\" . \"@@texinfo:@cite{@@$1@@texinfo:}@@\") (\"author\" . \"The Org Mode Developers\") (\"email\") (\"title\" .
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-C.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-R.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-awk.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-calc.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-clojure.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-comint.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-core.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-css.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-ditaa.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-dot.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-emacs-lisp.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-eshell.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-eval.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-exp.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-forth.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-fortran.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-gnuplot.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-groovy.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-haskell.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-java.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-js.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-julia.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-latex.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-lilypond.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-lisp.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-lob.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-lua.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-makefile.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-matlab.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-maxima.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-ocaml.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-octave.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-org.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-perl.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-plantuml.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-processing.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-python.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-ref.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-ruby.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-sass.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-scheme.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-screen.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-sed.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-shell.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-sql.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-sqlite.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-table.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob-tangle.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ob.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/oc-basic.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/oc-biblatex.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/oc-bibtex.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/oc-csl.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/oc-natbib.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/oc.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-bbdb.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-bibtex.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-docview.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-doi.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-eshell.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-eww.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-gnus.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-info.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-irc.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-man.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-mhe.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-rmail.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol-w3m.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ol.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-agenda.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-archive.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-attach-git.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-attach.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-capture.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-clock.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-colview.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-compat.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-crypt.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-ctags.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-cycle.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-datetree.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-duration.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-element-ast.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-element.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-entities.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-faces.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-feed.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-fold-core.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-fold.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-footnote.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-goto.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-habit.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-id.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-indent.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-inlinetask.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-keys.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-lint.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-list.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-loaddefs.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-macro.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-macs.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-mobile.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-mouse.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-num.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-pcomplete.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-persist.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-plot.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-protocol.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-refile.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-src.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-table.el...

In org-table-make-reference:
org-table.el:2867:23: Warning: ‘eq’ called with literal string that may never match (arg 2)
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-tempo.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-timer.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org-version.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/org.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-ascii.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-beamer.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-html.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-icalendar.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-koma-letter.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-latex.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-man.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-md.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-odt.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-org.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-publish.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox-texinfo.el...
Compiling /tmp/straight.el-test-d3MqE5/straight/build/org/ox.el...
Checking /tmp/straight.el-test-d3MqE5/straight/build/org/etc...
Checking /tmp/straight.el-test-d3MqE5/straight/build/org/etc/styles...
Done (Total of 126 files compiled, 2 skipped)
"

Packages:
"straight"                n/a                  develop 325f2ca 2023-08-01
"org-elpa"                n/a                  n/a
"melpa"                   n/a                  master fc5b27dd 2023-08-07
"gnu-elpa-mirror"         n/a                  master be1351c 2023-07-14
"nongnu-elpa"             n/a                  main 65b952d 2023-08-04
"el-get"                  melpa                master f3f1edd4 2023-07-25
"emacsmirror-mirror"      n/a                  master 8e7cbfe 2023-08-07
"org"                     org-elpa             main f9e083086 2023-08-07

That wouldn't prevent the loading of a stale version of Org if it were in straight/build/org/, though. My hunch is the same as before:
Org is being updated/rebuilt. It's dependents are not.
That's the general problem as I understand it.
Several policies could be adopted to solve this:

Method
Pros
Cons

Always rebuild a package's dependents when it is rebuilt

Easy to implement
User does not have to make any decisions

Wasteful most of the time
Rebuilds will take longer (slows package development workflow)

Detect cases where dependents need to be rebuilt

Not as wasteful
User does not have to make any decisions

Harder to implement
Likely to be imperfect (but may be able to catch most common cases)

Let user decide (the current state of affairs)

No implementation necessary

User must decide (obviously not cutting it)

Perhaps a mixed approach would work, too.
Default to always re-compiling dependents.
Write a global minor mode, straight-package-developer-mode, which disables that behavior.

Test Case
(straight-bug-report
  :pre-bootstrap
  :post-bootstrap
  (straight-use-package
   '(org :type git :repo
	 "https://git.savannah.gnu.org/git/emacs/org-mode.git"))
  (straight-use-package
   '(org-timeblock :host github :repo "ichernyshovvv/org-timeblock"))
  (with-temp-file (make-temp-file "straight-test")
    (insert "* Heading\n<2023-08-07 Mon 18:00-20:00>") (org-mode)
    (goto-char 1) (require 'org-timeblock) (org-timeblock-construct-id)))

Test run at: 2023-08-07 20:52:01
system-type: gnu/linux
straight-version: prerelease (HEAD -> develop, origin/develop) 325f2ca 2023-08-01
emacs-version: GNU Emacs 30.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-08-04

Output
Bootstrapping straight.el...
Bootstrapping straight.el...done
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...done
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...done
Looking for emacsmirror-mirror recipe → Cloning el-get...
Looking for emacsmirror-mirror recipe → Cloning el-get...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done

Test run with version: prerelease (HEAD -> develop, origin/develop) 325f2ca 2023-08-01
Cloning org...
Cloning org...done
Building org...
Building org...done
Cloning org-timeblock...
Cloning org-timeblock...done
Building org-timeblock...
Building org-timeblock → Cloning compat...
Building org-timeblock → Cloning compat...done
Building org-timeblock → Building compat...
Building org-timeblock → Building compat...done
Building org-timeblock → Cloning org-ql...
Building org-timeblock → Cloning org-ql...done
Building org-timeblock → Building org-ql...
Building org-timeblock → Building org-ql → Cloning dash.el...
Building org-timeblock → Building org-ql → Cloning dash.el...done
Building org-timeblock → Building org-ql → Building dash...
Building org-timeblock → Building org-ql → Building dash...done
Building org-timeblock → Building org-ql → Cloning f.el...
Building org-timeblock → Building org-ql → Cloning f.el...done
Building org-timeblock → Building org-ql → Building f...
Building org-timeblock → Building org-ql → Building f → Cloning s.el...
Building org-timeblock → Building org-ql → Building f → Cloning s.el...done
Building org-timeblock → Building org-ql → Building f → Building s...
Building org-timeblock → Building org-ql → Building f → Building s...done
Building org-timeblock → Building org-ql → Building f...
Building org-timeblock → Building org-ql → Building f...done
Building org-timeblock → Building org-ql → Cloning map...
Building org-timeblock → Building org-ql → Cloning map...done
Building org-timeblock → Building org-ql → Building map...
Building org-timeblock → Building org-ql → Building map...done
Building org-timeblock → Building org-ql → Cloning org-super-agenda...
Building org-timeblock → Building org-ql → Cloning org-super-agenda...done
Building org-timeblock → Building org-ql → Building org-super-agenda...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ht.el...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ht.el...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ht...
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ht...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ts.el...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ts.el...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ts...
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ts...done
Building org-timeblock → Building org-ql → Building org-super-agenda...
Building org-timeblock → Building org-ql → Building org-super-agenda...done
Building org-timeblock → Building org-ql → Cloning ov...
Building org-timeblock → Building org-ql → Cloning ov...done
Building org-timeblock → Building org-ql → Building ov...
Building org-timeblock → Building org-ql → Building ov...done
Building org-timeblock → Building org-ql → Cloning peg...
Building org-timeblock → Building org-ql → Cloning peg...done
Building org-timeblock → Building org-ql → Building peg...
Building org-timeblock → Building org-ql → Building peg...done
Building org-timeblock → Building org-ql → Cloning transient...
Building org-timeblock → Building org-ql → Cloning transient...done
Building org-timeblock → Building org-ql → Building transient...
Building org-timeblock → Building org-ql → Building transient...done
Building org-timeblock → Building org-ql...
Building org-timeblock → Building org-ql...done
Building org-timeblock → Cloning svg...
Building org-timeblock → Cloning svg...done
Building org-timeblock → Building svg...
Building org-timeblock → Building svg...done
Building org-timeblock...

If MARKER is nil, use entry at point.
If EVENTP is non-nil, use entry's TIMESTAMP property."
  (let ((element (org-with-point-at marker (org-element-at-point))))
    (md5
     (concat
      (org-element-property :raw-value element)
      (if eventp
	  (org-entry-get marker "TIMESTAMP")
	(concat
	 "S"
	 (org-element-property
	  :raw-value
	  (org-element-property :scheduled element)))))
     nil nil 'utf-8)))

And org-element-property inside is inlined, but inlined from built-in Org version; not from the savannah repo.

And org-element-property inside is inlined, but inlined from built-in Org version; not from the savannah repo.

If that were the case, I'd expect to see the same error when adding:
(eval-when-compile (require 'org-element-ast))

to org-timeblock.el.
However, everything works when that is done.

Test Case
(straight-bug-report
  :post-bootstrap
  (setq straight-disable-native-compile t)
  (straight-use-package 'org)
  (straight-use-package
   '(org-timeblock :host github :repo "progfolio/org-timeblock" :branch
                   "maybe/fix"))
  (with-temp-file (make-temp-file "straight-test")
    (insert "* Heading\n<2023-08-07 Mon 18:00-20:00>") (org-mode) (goto-char 1)
    (require 'org-timeblock) (print (org-timeblock-construct-id))))

Test run at: 2023-08-07 21:05:18
system-type: gnu/linux
straight-version: prerelease (HEAD -> test/compile, fork/test/compile) f1bd659 2023-08-07
emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-07-25

Output
Bootstrapping straight.el...
Bootstrapping straight.el...done
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...done
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...done
Looking for emacsmirror-mirror recipe → Cloning el-get...
Looking for emacsmirror-mirror recipe → Cloning el-get...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done

Test run with version: prerelease (HEAD -> develop, origin/develop) 095aee3 2023-08-07
Cloning org...
Cloning org...done
Building org...
Building org...done
Cloning org-timeblock...
Cloning org-timeblock...done
Building org-timeblock...
Building org-timeblock → Cloning compat...
Building org-timeblock → Cloning compat...done
Building org-timeblock → Building compat...
Building org-timeblock → Building compat...done
Building org-timeblock → Cloning org-ql...
Building org-timeblock → Cloning org-ql...done
Building org-timeblock → Building org-ql...
Building org-timeblock → Building org-ql → Cloning dash.el...
Building org-timeblock → Building org-ql → Cloning dash.el...done
Building org-timeblock → Building org-ql → Building dash...
Building org-timeblock → Building org-ql → Building dash...done
Building org-timeblock → Building org-ql → Cloning f.el...
Building org-timeblock → Building org-ql → Cloning f.el...done
Building org-timeblock → Building org-ql → Building f...
Building org-timeblock → Building org-ql → Building f → Cloning s.el...
Building org-timeblock → Building org-ql → Building f → Cloning s.el...done
Building org-timeblock → Building org-ql → Building f → Building s...
Building org-timeblock → Building org-ql → Building f → Building s...done
Building org-timeblock → Building org-ql → Building f...
Building org-timeblock → Building org-ql → Building f...done
Building org-timeblock → Building org-ql → Cloning map...
Building org-timeblock → Building org-ql → Cloning map...done
Building org-timeblock → Building org-ql → Building map...
Building org-timeblock → Building org-ql → Building map...done
Building org-timeblock → Building org-ql → Cloning org-super-agenda...
Building org-timeblock → Building org-ql → Cloning org-super-agenda...done
Building org-timeblock → Building org-ql → Building org-super-agenda...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ht.el...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ht.el...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ht...
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ht...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ts.el...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ts.el...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ts...
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ts...done
Building org-timeblock → Building org-ql → Building org-super-agenda...
Building org-timeblock → Building org-ql → Building org-super-agenda...done
Building org-timeblock → Building org-ql → Cloning ov...
Building org-timeblock → Building org-ql → Cloning ov...done
Building org-timeblock → Building org-ql → Building ov...
Building org-timeblock → Building org-ql → Building ov...done
Building org-timeblock → Building org-ql → Cloning peg...
Building org-timeblock → Building org-ql → Cloning peg...done
Building org-timeblock → Building org-ql → Building peg...
Building org-timeblock → Building org-ql → Building peg...done
Building org-timeblock → Building org-ql → Cloning transient...
Building org-timeblock → Building org-ql → Cloning transient...done
Building org-timeblock → Building org-ql → Building transient...
Building org-timeblock → Building org-ql → Building transient...done
Building org-timeblock → Building org-ql...
Building org-timeblock → Building org-ql...done
Building org-timeblock → Cloning svg...
Building org-timeblock → Cloning svg...done
Building org-timeblock → Building svg...
Building org-timeblock → Building svg...done
Building org-timeblock...

If that were the case, I'd expect to see the same error when adding:
(eval-when-compile (require 'org-element-ast))

to org-timeblock.el.
However, everything works when that is done.

org-element-ast is absent from built-in Org mode. This file was only
added in the development version of Org.
So, it could be that built-in org-element.el is loaded somehow, defining
inappropriate inline expansion for org-element-property.
Explicitly loading org-element-ast will re-define the inline expansion,
if org-element-ast.el is at all present in the load-path.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Should be fixed by #1109

Test Case
(straight-bug-report
  :pre-bootstrap
  (setq straight-repository-user "progfolio" straight-repository-branch
        "fix/compile" debug-on-error t)
  :post-bootstrap
  (straight-use-package 'org)
  (straight-use-package
   '(org-timeblock :host github :repo "ichernyshovvv/org-timeblock"))
  (with-temp-file (make-temp-file "straight-test")
    (insert "* Heading\n<2023-08-07 Mon 18:00-20:00>") (org-mode) (goto-char 1)
    (require 'org-timeblock) (print (org-timeblock-construct-id))))

Test run at: 2023-08-08 19:20:30
system-type: gnu/linux
straight-version: prerelease (HEAD -> fix/compile, fork/fix/compile) 72ad2a5 2023-08-08
emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-07-25

Output
Bootstrapping straight.el...
Bootstrapping straight.el...done
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...
Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...done
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...
Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...done
Looking for emacsmirror-mirror recipe → Cloning el-get...
Looking for emacsmirror-mirror recipe → Cloning el-get...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done

Test run with version: prerelease (HEAD -> fix/compile, origin/fix/compile) 72ad2a5 2023-08-08
Cloning org...
Cloning org...done
Building org...
Building org...done
Cloning org-timeblock...
Cloning org-timeblock...done
Building org-timeblock...
Building org-timeblock → Cloning compat...
Building org-timeblock → Cloning compat...done
Building org-timeblock → Building compat...
Building org-timeblock → Building compat...done
Building org-timeblock → Cloning org-ql...
Building org-timeblock → Cloning org-ql...done
Building org-timeblock → Building org-ql...
Building org-timeblock → Building org-ql → Cloning dash.el...
Building org-timeblock → Building org-ql → Cloning dash.el...done
Building org-timeblock → Building org-ql → Building dash...
Building org-timeblock → Building org-ql → Building dash...done
Building org-timeblock → Building org-ql → Cloning f.el...
Building org-timeblock → Building org-ql → Cloning f.el...done
Building org-timeblock → Building org-ql → Building f...
Building org-timeblock → Building org-ql → Building f → Cloning s.el...
Building org-timeblock → Building org-ql → Building f → Cloning s.el...done
Building org-timeblock → Building org-ql → Building f → Building s...
Building org-timeblock → Building org-ql → Building f → Building s...done
Building org-timeblock → Building org-ql → Building f...
Building org-timeblock → Building org-ql → Building f...done
Building org-timeblock → Building org-ql → Cloning map...
Building org-timeblock → Building org-ql → Cloning map...done
Building org-timeblock → Building org-ql → Building map...
Building org-timeblock → Building org-ql → Building map...done
Building org-timeblock → Building org-ql → Cloning org-super-agenda...
Building org-timeblock → Building org-ql → Cloning org-super-agenda...done
Building org-timeblock → Building org-ql → Building org-super-agenda...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ht.el...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ht.el...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ht...
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ht...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ts.el...
Building org-timeblock → Building org-ql → Building org-super-agenda → Cloning ts.el...done
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ts...
Building org-timeblock → Building org-ql → Building org-super-agenda → Building ts...done
Building org-timeblock → Building org-ql → Building org-super-agenda...
Building org-timeblock → Building org-ql → Building org-super-agenda...done
Building org-timeblock → Building org-ql → Cloning ov...
Building org-timeblock → Building org-ql → Cloning ov...done
Building org-timeblock → Building org-ql → Building ov...
Building org-timeblock → Building org-ql → Building ov...done
Building org-timeblock → Building org-ql → Cloning peg...
Building org-timeblock → Building org-ql → Cloning peg...done
Building org-timeblock → Building org-ql → Building peg...
Building org-timeblock → Building org-ql → Building peg...done
Building org-timeblock → Building org-ql → Cloning transient...
Building org-timeblock → Building org-ql → Cloning transient...done
Building org-timeblock → Building org-ql → Building transient...
Building org-timeblock → Building org-ql → Building transient...done
Building org-timeblock → Building org-ql...
Building org-timeblock → Building org-ql...done
Building org-timeblock → Cloning svg...
Building org-timeblock → Cloning svg...done
Building org-timeblock → Building svg...
Building org-timeblock → Building svg...done
Building org-timeblock...
 Hope that it was the only org 9.7-related issue.