How does navigation work with , etc?

I'm converting an old abandoned, but partially working project from non-react Framework7 to Framework7+React+Redux.  I'm barely familiar with React/Redux at this point, but I like JSX.  I'm having trouble separating out the best practices of the various scenarios to make this work.  I'm aiming for a DOM Cache inline-style with dynamic navbars.
I have my app to the point where my default Page loads correctly in the main view.  But I can't get the navigation links to work.  I have <Framework7App onFramework7Init={() => store.dispatch(navigateTo('/'))} routes={Routes} themeType="ios" router={false} stateKernel={framework7StateKernel}> and that all seems to be necessary.
But I can't get links to work.  These seem discouraged in framework7-redux:
<Link href="/about/">About App</Link>
<Link href="/login/">Login</Link>

or
<Link onClick={() => getFramework7().mainView.router.loadPage('/about/')}>About</Link>
<Link onClick={() => getFramework7().mainView.router.back()}>Go Back</Link>

but I don't know how to really make use of this instead:
//Go to page 1
store.dispatch(navigateTo('/page-1/'));

//Go back to the home page
store.dispatch(goBack());

Can you please elaborate on it?
Thanks!

This project is still pretty new, and I still need to put together some examples. In the meantime, see if this helps:
//HomePage.jsx

const HomePage = ({onAboutSelected, onBackSelected}) => (
	...
	<Link onClick={onGoBackSelected}>Go Back</Link>
	<Link onClick={onAboutSelected}>About App</Link>
	...
);

//HomeActions.js

import {navigateTo, goBack} from 'framework7-redux';

export const backSelected = () => {
	return goBack();
};

export const aboutSelected = () => {
	return navigateTo('/about/');
};

//HomePageContainer.jsx

import {connect} from 'react-redux';
import {goBackSelected, aboutSelected} from './actions/HomeActions';

import {HomePage} from './components/HomePage';

const mapDispatchToProps = dispatch => {
	return {
		onBackSelected: dispatch(backSelected()),
		onAboutSelected: dispatch(aboutSelected())
	};
};

export const HomePageContainer = connect(
  null,
  mapDispatchToProps
)(HomePage);

//routes.js

import {HomePageContainer} from './containers/HomePageContainer';
import {AboutPageContainer} from './containers/AboutPageContainer';

export const routes = [{
	path: '/',
	component: HomePageContainer
}, {
	path: '/about/',
	component: AboutPageContainer
}];

Alright!  Almost there I think.
Any idea about this runtime error?  What did I miss?
Uncaught TypeError: Cannot read property 'route' of undefined
    at HistoryReconciler.get [as currentF7HistoryPagePath] (http://localhost:8888/app.js:42265:103)
    at HistoryReconciler.fastForwardToFirstNonMatchingPage (http://localhost:8888/app.js:42278:77)
    at HistoryReconciler.getOperationsToReconcileHistories (http://localhost:8888/app.js:42239:14)
    at RoutingKernel.reconcileHistories (http://localhost:8888/app.js:42190:14)
    at RoutingKernel.handleStateChange (http://localhost:8888/app.js:42171:14)
    at RoutingKernel.StateKernel.setState (http://localhost:8888/app.js:7704:18)
    at http://localhost:8888/app.js:7708:19
    at Array.forEach (native)
    at Framework7StateKernel.StateKernel.setState (http://localhost:8888/app.js:7707:23)
    at Array.<anonymous> (http://localhost:8888/app.js:41951:21)

It looks like you might not have passed your framework7StateKernel into your Framework7App component, which would result in some things not getting initialized properly. Hopefully this will help:
import {Provider} from 'react-redux';
import {store, framework7StateKernel} from './store';

<Provider store={store}>
  <Framework7App
    themeType={'ios'}
    routes={routes}
    router={false}
    stateKernel={framework7StateKernel}
  >
  ...
  </Framework7App>
</Provider>

I think I have it exactly like that.  I'm using the dom cache mode where everything is already loaded and available without any followup downloads necessary from the server - does that make a difference?  I tried adding <Framework7App ... cache> but that had no immediate effect.

Using the DOM cache like the kitchen sink does is the default way of working, so there shouldn't be any problems there. Are you still having issues getting it to work or did you figure it out? Guess I really need to put a working example / template out soon there so people won't have to spend as much time trying to get it working.

I did not figure it out yet.  Seems like findMatchingRoute() in history-reconciler.js cannot resolve findMatchingRoute("#Today") from this routes object:
[{
  path: '#Today',
  component: Today
},{
  path: '#MyAccount',
  component: MyAccount
}];

I'm still unable to get routing to work at all.

I believe it is getting #Today from <Page name="Today" /> being the non-cached view.  So when I click on any link, for example dispatch(navigateTo("#MyAccount")), the currentF7HistoryPagePath fails to findMatchingRoute("#Today") and I get the type error.

Even if I try to replace "#Today" with "/Today" in all places, the current history is still "#Today".  I've also tried making links go to "/MyAccount" and just "MyAccount" but it makes no difference.
Any thoughts?
Thanks

Ok, I think this is mostly because #Today was my main Page and among my routes, but the url is / when it loads (which matches none of my explicit routes) and not #Today, /Today/, nor Today so it can't find the previous route.  If I change my routes and links to be / then I get further - the page name can stay as Today.  Is there more you can explain about the custom routing mechanism here?

I don't know if this is all part of the same mistake I've made or if it should be a different issue, but the next thing I run into is that self.$parent is undefined in onRouteChange on one of the iterations.  I'm trying to track through the code to find out what self is and why it has no $parent, but I'm having a very difficult time of that.


Add feature option search

Description
This PR adds a feature option search to Refined GitHub's option popup.
Searching for open batch will only return one result ("batch-open-issues"); the order of the words doesn't matter. Under the hood, this makes sure that every word in the search pattern matches some part of the feature name and description.
Notes:

This only searches the feature name & description.
All matches are case-insensitive.
The following characters are ignored: ,.:;'"’`.
The following character is replaced with a space: -; this allows "open-batch to still match "batch-open-issues"

Screenshots

Closes
Closes #2147
Test
Open Refined-GitHub's options

Great to see this!
I don't think one ever needs the "non-exact" search, which seems to me it's just an "keyword OR keyword" search. If I enter more words, I want all of them to appear.
For the implementation, have a look at this, it's shorter:
https://github.com/HangYang/one-click-extensions-manager/blob/1ac4566f7d28329c98ce8f0edc7a380a8ce9ecf7/src/popup.js#L94-L102

I removed the basic match and rebased from the master. This made my screenshot dark 😺
Oh, you've updated your comment with code... I replaced some of the punctuation in the search because it's not so easy to type ’ on some computers.

Ok, I've updated the code. The search from the screenshot doesn't work the same because there are no longer any string replacements.

Also everything should be renamed to filter rather than search https://ux.stackexchange.com/a/4756/35104

Umm, please go ahead and make these changes... I'm having some issues with my computer.
Apparently running npm install now makes my computer reboot.
Then I saw this:

And after a repair:

I think I'm gonna call it a night LOL

So... npm install is still having issues, but apparently yarn install worked.
Then YAY, I made the changes.
npm test failed and was showing some weird error message. yarn test caused a GSOD (apparently Windows insider now shows a green-screen of death vs the older, outdated blue-screen of death).
Tests seem to be passing here (finally) LOL... I still don't know how to deal with the feature.dataset.text TS error other than wrapping it in a String().
Now, I'm going to bed.

And oops... I removed the [hidden] { display: none; } so now the features aren't getting hidden.

And oops... I removed the [hidden] { display: none; } so now the features aren't getting hidden.

Uhm, what browser are you using? It works correctly in both Firefox and Chrome for me

👍 Thanks for the fixes! Typescript is still weird to me.

Great work @Mottie 👍


default value for numbers

I'm using this project to control my boiler.
for the CH temperature I'm using PID which works great.
for DHW I want to simply use a number to a set temperature but every time the ESP reboots, I have to set it again.
I didn't find a way to specify a default value. Am I missing something or could it be added as an option?

Thank you for the pointers, I'll give it a try!


Q2 PROD - Primary Party inverseOf  playsActiveRoleIn

The owl:inverseOf looks like a bug:
https://spec.edmcouncil.org/fibo/ontology/master/2020Q2/prod.ttl.zip
fibo-fnd-pty-pty:hasPrimaryParty
  rdf:type owl:ObjectProperty ;
  rdfs:comment "QName: fibo-fnd-pty-pty:hasPrimaryParty" ;
  rdfs:isDefinedBy fibo-fnd-pty-pty: ;
  rdfs:label "has primary party" ;
 owl:inverseOf fibo-fnd-pty-pty:playsActiveRoleIn ;
  owl:propertyChainAxiom (
      fibo-fnd-pty-pty:hasActor
      fibo-fnd-pty-rl:isPlayedBy
    ) ;
  <http://www.w3.org/2004/02/skos/core#definition> "relates a situation to the person or organization acting in a primary (agentive) role" ;
.

Hi Jurgen,
This is part of a set of patterns added to cover lattice relations, especially for ownership and control relationships between roles - what about this looks incorrect to you?  We are attempting to create better patterns and normalize the properties for some of these reified relations, which will include control, beneficial ownership, etc., fyi.  There will be more revisions that use these over the next month or so, but what's there has been tested with our example data for subsidiaries, holding companies, etc.  People often choose the wrong ones, resulting in reasoning errors.
Best,
Elisa


#1896 a: func b, {c: d} fix

The latest patch appears to fix #1896 and #1865 except for the rewinding issue mentioned by Jeremy (which should be straightforward to fix).
Test cases added for current expected behavior without accounting for rewinding behavior.

I got around to merging scanEnd and detectEnd, and making davidchamber's suggested edits.
I'm pretty happy with the result.


Changed void Buy and void Sell to bool Buy and bool Sell

More advanced for devs.

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


LUCENE-10400: revise binary dictionaries' constructor in nori

This applies the same changes as #643 to Nori.

Add new constructors that take Path objects to load external resources.
Add tests for the new constructors.
Deprecate the old constructors to switch the resource location (classpath/file path).
Always use Class.getResourceAsStream() to load class resources.

We will also have a second PR to remove the deprecated APIs in main branch?

Yes, I will.


Refactor engine package structure

Description
Refactors package structure for engines:

First, it renames the package from util to engine
Next, it moves actual utils to the util package
Lastly, it puts the engines (faiss, lucene, nmslib) in separate sub-packages. Purpose for this is to separate between engines.

In order to support quantization framework, some refactoring needs to be done. This is the first step. After this, I am planning on changing up the KNNMethod interface and how Methods are defined for engines.
Keeping scope of this PR limited to change of package only, just because it touches so many files. For comments that are not related to package change, we can address in upcoming PRs.
Ill make sure neural-search is updated as well.
Related Issues
Previous PR I opened then closed yesterday: #1908. I changed my mind and think it would be good to do this refactor upfront.
Check List

[X] Commits are signed per the DCO using --signoff.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

The scope of the refactor doesn't seem to be clear. this PR is package related but to what extent are things being moved around, are they tied to specific release?

I wouldn't want this in main until its complete. Does it make more sense to push this in quantization framework branch since they seem to be related from description?

As long as we are sure that there won't be a complete new package layout change again during quantization implementation, I think this change is harmless. Doing this early in main will reduce merging effort compared to do it later.

The scope of the refactor doesn't seem to be clear. this PR is package related but to what extent are things being moved around, are they tied to specific release?

I wanted to address the following in this PR:

util is a bad package for all of the engine components to be in. I wanted to move the engine components to their own package. Then, keep the utils package for actual utilities. Better defining these constructs will make it easier to develop on top of
Putting engines in separate packages. This is an incremental step in separating the engines, which I think from a long term maintainability perspective we are going to want to do more and more.
Move KNNMethod and MethodComponents into engine. I forgot to mention this in description. These are the components that define the methods the engines support. So, I think it makes sense to define them in the engine. Yes, they may be used elsewhere, but I think they are a central part of the engine construct.

I didnt include any other code in this PR just to keep focus narrow - functionality should not change.
In general, my goal is to make incremental changes to improve structure of code.

In general, my goal is to make incremental changes to improve structure of code.

+1 on this, the repo needs better package structure. My concern is more over reverts if we have to do it. 1 commit to revert is better than multiple

+1 on this, the repo needs better package structure. My concern is more over reverts if we have to do it. 1 commit to revert is better than multiple

Right, if this change had to be reverted it would be a pain for everyone after. I think this change is pretty low-risk because functionality is not changing just package structure. Issues will be caught at compile time. So I think that there is a very small chance we have to revert as opposed to making a minor fix.


dcpaccess.py - add -o option

add output option for dcpacces.py
i should have a go at seeing if i can do this.

SOunds good Raelene - At a glance, searching for instances of the word 'Desktop' would show you where you'd have to do some editing.

cool, - thanks for the signpost

so i took a long look at this over the wknd and don't think i'll be able to do it without your help. it's much more complicated than bitc or prores because i think the output container format is built into the output location.
maybe we can look at it together at some stage

Sounds good. This script does some good stuff and analyses dcps pretty well
but it is not terribly well structured and therefore difficult to edit.


Added support for Turbolinks 5

Turbolinks 5 has new event names. This change adds an event listener for the new event, which functions similarly to the page:change event in previous versions.

Thx @briank-musichouse


Add: Canva and Designs AI

Description
The purpose of this pull request is to addition of couple of AI tools which can be used for design generation.
Checklist
Before submitting this pull request, please ensure that you have done the following:

[x] Read and understood the Contributing Guidelines.
[x] Checked that your changes align with the repository's goals and content.
[x] The submission is not already present in the list

New addition
This commit will add AI tools for design generator. Those are,

Canva
Designs AI

Author
Suraj Khamkar
<EMAIL_ADDRESS>

Hello @Hyraze,
Please review my changes and let me know if there are any changes required.


AWS attributes: dynamic evaluation?

The README states
  # Set custom options such as cache control to leverage browser caching
  config.aws_attributes = {
    expires: 1.week.from_now.httpdate,
    cache_control: 'max-age=604800'
  }

However, the statement 1.week.from_now.httpdate will return a static, absolute timestamp which is then merged verbatim into the request. So when an application runs for a couple of days, the expires string will move closer and closer, eventually even moving into the past.
It should be straightforward to also have this support a lambda or Proc instead of a static hash, so it can be evaluated on every request. What do you think about this?

Noting this issue as resolved - an associated PR has been merged.

Thanks for noting it has been fixed. It slipped through the cracks.


Roll Flutter Engine from a5fbe512a6aa to fb05a6b17be2 (1 revision)

https://github.com/flutter/engine/compare/a5fbe512a6aa...fb05a6b17be2
2022-06-01<EMAIL_ADDRESS>Roll Skia from b21740086944 to 1da7be7a8516 (2 revisions) (flutter/engine#33748)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Additional message flags

getFlags() returns array with some additional message flags:
recent - this message is flagged as recent
flagged - this message is flagged
answered - this message is flagged as answered
deleted - this message is flagged for deletion
seen - this message is flagged as already read
draft - this message is flagged as being a draft

Need to be improved. I'll send a new pull request.


Port users_db_security javascript tests to elixir

Overview
This PR ports users_db_security.js tests into the elixir test suite. During the porting of this test I needed to add support for raw responses to Couch.Session module.
This is the last active test to be ported from the javascript test suite. The javascript test suite can be removed from the main build process as there are no more test being ran. I'll prepare a separate PR for this.

Testing recommendations
make javascript All test should be skipped or ported
make elixir All test should pass

Related Issues or Pull Requests
N/A

Checklist

[X] Code is written and works correctly
[X] Changes are covered by tests
[ ] Any new configurable parameters are documented in rel/overlay/etc/default.ini
[ ] A PR for documentation changes has been made in https://github.com/apache/couchdb-documentation

Tests are red 🚨 did the modification to couch.ex affect some older stuff maybe?

oops... The problem with this test is that it is using _users database. If I'm not properly cleaning it we can have a side effect... I'll check it.
couch.ex changes are not the problem here. It's the execution order.

Thanks for checking!

I've rewritten the test cleaning process.  I remove each user that has been previously created.
Now, it does not collide with any other test.
Thanks!

Thanks!! the last one :tada:

@jjrodrig is that the last JS test now?
If so, I can start the work to rip the JS test harness out of our build chain, makefiles, etc.

@wohali I'm just creating a PR that removes @$(MAKE) javascript from the check target
There are some tests that have not been ported. These tests are currently skipped in the JS test suite. I think, that the work is done.


Re-write/update section 2,2: Product Functionality of SRS

TODO By: Randall

Re-write/update section 2,2: Product Functionality of SRS


Cant use draft with csharp

Hi guys,
is there a way to get why daraft cannot pack c#?
And also why c# is recognized as xml?

I checked it with go language and it works, so this is not a local setup issue I suppose

Hey @profesor79! Can you give us more information on what version of draft you're running?

Curious that in your first screenshot it looks like the path it's looking for is ...\.draft\packs\ack=csharp. I haven't seen that before.

Hmm. draft create works just fine for me using the example ASP.NET application.
PS C:\Users\mafishe\go\src\github.com\Azure\draft\examples\csharp> draft create
--> Draft detected the primary language as csharp with 84.861307% certainty.
--> Ready to sail

Do you have a public repository that we can use to test against?

One PR that may assist with the language being detected as XML would be #344. If there is a large amount of code in your .csproj files then linguist is going to detect that a large majority of your codebase is written in XML. Once #344 is finalized and merged, you can fix this by writing out the following .gitattributes file in the root of your application:
*.csproj linguist-language=csharp

ping, any news on this front?

pong - will try to check that tomorrow and will revert here.

I'm going to close this issue due to inactivity and due to lack of being able to reproduce the issue locally, but please feel free to re-open and report back once you get an idea how it occurred. Thanks!


Replace while loop with do-while in snake.ts

Just a heads up: I haven’t tested this but I’m fairly certain the syntax is correct


Walker Air Transport VA Addition

Storm Walker, CEO of Walker Air Transport, grants you permission to redistribute the files and liveries for the use of the BlueBell CSL package.
 Our crews are quite active on Vatsim, would be nice to show our colours ;)

Done.
I could not add the Beluga, Baron, 727, Cessna, or Cirrus, as these are not repaints of aircraft that are already in the BB package. (And they are very large files so probably not suitable as CSL's anyway, too many polygons).

Fantastic, thanks so much!


Fix test coverage

Afternoon @aboutlo, I ran into the same issue in #28 after renaming one of my repos yesterday, and that may be the cause of the issue here as well?
This merge request adds test coverage generation to the CI GitHub Actions workflow.
After merging this pull request, I believe you can sort #28 by doing the following (as long as you have access to the Fastify coveralls group):

Navigate to https://coveralls.io/repos/new in the Fastify group and toggle the button next to fluent-json-schema to off
Navigate to https://coveralls.io/github/fastify/fluent-schema
you should see a Settings link above the Repo on GitHub link
Click the Settings link
Scroll down, click Delete Repo, and confirm deletion to remove the repo from coveralls
At this point i went to bed, so this probably gave it time to clear completely from coveralls system/cache
Rerun the latest CI job on the master branch of the repo (as long as the job has a step to generate coverage, it should then send coverage)

Thank you @Fdawgs! it was since forever I wanted this configured and I never had the time to do it
I think the repo is already configured: https://coveralls.io/github/fastify/fluent-json-schema
I did nothing so I guess it just your pull request that it sent the data :)
Can you add the badge to the readme too? 🙏

Thank you @Fdawgs! it was since forever I wanted this configured and I never had the time to do it
I think the repo is already configured: https://coveralls.io/github/fastify/fluent-json-schema
I did nothing so I guess it just your pull request that it sent the data :)
Can you add the badge to the readme too? 🙏

Hi @aboutlo, brilliant!
I'll sort out the badge and clean up the original pull request comment.

Hi @aboutlo, brilliant!
I'll sort out the badge and clean up the original pull request comment.


feat: PowerBi Logo for Dashboard mode PowerBi

Description
This addition of the powerbi feature will allow people to show the dashboard with powerbi logo instead of the default dashboard logo. Making the dashboard page more interactive.

@sbmittal389 please check the DCO task!


Add Profile credentials providers

Added a CredentialsChain which allows for the return-value to be null, permitting chaining operations
CredentialsChain.Profile gets from a local credentials file
CredentialsChain.Ec2InstanceProfile gets from the EC2 Instance Metadata Service
CredentialsProvider.Default will attempt to load credentials in the following order: Environment, Profile, Ec2InstanceProfile
Migrated existing clients to CredentialsProvider.Default

Tests are passing now; just the automerge test that's failing.

We're actually not at all fans of the credentials chain - so could you possibly at the very least remove the defaulting of it . We very specifically didn't implement the concept of the chain as we have had really bad experiences with not knowing where clients are getting their credentials and magic things happening - it's one of our big bug-bears with the AWS SDK.
I've fixed the automerge thing so at least PR builds shouldn't fail any more 😄

Fair enough; I've reverted the change to the default CredentialsProvider, and I've updated the nomenclature of the default chain.  I like the default chain from the SDK because it means I don't need to worry about where the code is being run; be it on a developer machine, on an EC2, or in a Lambda.  But at least I still have the option to use it.
I can't really restore the composite AWS_CREDENTIALS Environment Lens, because I still need the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to be optional for the chained version... unless you want optional duplicates.

Codecov Report

Merging #152 (ef4ba8b) into master (231dff4) will increase coverage by 0.00%.
The diff coverage is 65.33%.

@@            Coverage Diff            @@
##             master     #152   +/-   ##
=========================================
  Coverage     64.54%   64.55%
  Complexity      733      733
=========================================
  Files           398      402    +4
  Lines          4434     4505   +71
  Branches        360      378   +18
=========================================
+ Hits           2862     2908   +46
- Misses         1361     1374   +13
- Partials        211      223   +12

Impacted Files
Coverage Δ

...n/org/http4k/connect/amazon/CredentialsProvider.kt
0.00% <0.00%> (ø)

.../credentials/ec2InstanceProfileCredentialsChain.kt
62.85% <62.85%> (ø)

...amazon/core/credentials/profileCredentialsChain.kt
66.66% <66.66%> (ø)

...onnect/amazon/core/credentials/CredentialsChain.kt
80.00% <80.00%> (ø)

...rg/http4k/connect/amazon/core/model/ProfileName.kt
100.00% <100.00%> (ø)

...ain/kotlin/org/http4k/connect/amazon/extensions.kt
100.00% <100.00%> (ø)

.../org/http4k/connect/amazon/dynamodb/DynamoTable.kt
83.33% <0.00%> (-8.34%)
:arrow_down:

...http4k/connect/amazon/dynamodb/model/extensions.kt
100.00% <0.00%> (+16.66%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

I can't really restore the composite AWS_CREDENTIALS Environment Lens, because I still need the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to be optional for the chained version... unless you want optional duplicates.

Can we please keep these as required and have the duplicates just in the chain (and have the AWS_CREDENTIALS lens restored)? We use these all over the place so it would be a really disruptive change 😄

No problem; I've restored it.

Actually, I just realized something.  I believe CredentialsProvider is invoked per request, which means I'm going to have to implement caching for the Profile and especially the Ec2InstanceProfile chains.  The latter will most likely require that I honour the expiration of the STS credentials.

Ok - let me know when you think it's ready 😄


Production build

when i try to build in production mode a get this error:
> ionic build android --prod
ionic-app-scripts build "--prod"
[22:22:55]  ionic-app-scripts 1.1.3
[22:22:55]  build prod started ...
[22:22:55]  clean started ...
[22:22:55]  clean finished in 2 ms
[22:22:55]  copy started ...
[22:22:55]  ngc started ...
can't resolve module<EMAIL_ADDRESS>from<EMAIL_ADDRESS>[22:22:59]  build prod failed: can't find symbol KeyRegistry exported from module
<EMAIL_ADDRESS>[22:22:59]  ionic-app-script task: "build"
[22:22:59]  Error: can't find symbol KeyRegistry exported from module
<EMAIL_ADDRESS>Error: can't find symbol KeyRegistry exported from module<EMAIL_ADDRESS>at ReflectorHost.findDeclaration (/Users/user/Develop/vvCremaIonic/ionic2/vvApp/node_modules/@angular/compiler-cli/src/reflector_host.js:173:23)
at /Users/user/Develop/vvCremaIonic/ionic2/vvApp/node_modules/@angular/compiler-cli/src/codegen.js:137:46
at Array.forEach (native)
at extractProgramSymbols (/Users/user/Develop/vvCremaIonic/ionic2/vvApp/node_modules/@angular/compiler-cli/src/codegen.js:120:10)
at CodeGenerator.codegen (/Users/user/Develop/vvCremaIonic/ionic2/vvApp/node_modules/@angular/compiler-cli/src/codegen.js:57:29)
at Object.runCodegen (/Users/user/Develop/vvCremaIonic/ionic2/vvApp/node_modules/@ionic/app-scripts/dist/aot/codegen/codegen-ng22.js:15:26)
at Object.doCodegen (/Users/user/Develop/vvCremaIonic/ionic2/vvApp/node_modules/@ionic/app-scripts/dist/aot/codegen.js:6:31)
at /Users/user/Develop/vvCremaIonic/ionic2/vvApp/node_modules/@ionic/app-scripts/dist/aot/aot-compiler.js:41:30
npm ERR! Darwin 16.4.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "ionic:build" "--" "--prod"
npm ERR! node v7.7.1
npm ERR! npm  v4.3.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! vvapp@ ionic:build: ionic-app-scripts build "--prod"
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the vvapp@ ionic:build script 'ionic-app-scripts build "--prod"'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the vvapp package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     ionic-app-scripts build "--prod"
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs vvapp
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls vvapp
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/user/.npm/_logs/2017-03-23T21_22_59_438Z-debug.log

my package.json:
"dependencies": {
"@angular/common": "2.4.8",
"@angular/compiler": "2.4.8",
"@angular/compiler-cli": "2.4.8",
"@angular/core": "2.4.8",
"@angular/forms": "2.4.8",
"@angular/http": "2.4.8",
"@angular/platform-browser": "2.4.8",
"@angular/platform-browser-dynamic": "2.4.8",
"@angular/platform-server": "2.4.8",
"@ionic/storage": "2.0.0",
"ionic-angular": "2.3.1",
"ionic-img-viewer": "^1.3.0",
"ionic-native": "3.1.0",
"ionicons": "3.0.0",
"rxjs": "5.0.1",
"sw-toolbox": "3.4.0",
"zone.js": "0.7.2"
},
"devDependencies": {
"@ionic/app-scripts": "1.1.4",
"typescript": "2.0.9"
},

Hello, Have the same issue any news ?

"ionic-angular": "2.3.1"  => is it even released yet ? I'm not sure.
There might be an issue with v2.3.0 (released just a few days ago), I will try later on today.
Thanks for opening an issue

Probably a duplicate of #41 - closing it as no info.


There didn't seem to be anything else running at the time, so I don't know why that was (and it could be difficult to find out: maybe the room the machine is in was warmer on one day or something).  I'll see if I can confirm that by running the benchmarks on several different days when the machine's quiet.


mark required fields in create service user

Describe the bug
At the moment there is no mark which fields are required when i want to create a service account
To Reproduce
Steps to reproduce the behavior:

Go to service accounts
click "new"-button

Expected behaviour
There should behind the title of the input field
Screenshots

:tada: This issue has been resolved in version 1.2.6 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

This is now deployed on zitadel.ch


Create Lushootseed Keyboard

Need a Lushootseed "lut" keyboard for Chromebooks.

I am going to close this pull request and open a issue to track the request.


Separate eager and lazy APIs

A lot of thought and effort is going into this, so I hope people will be open to at least considering it. No worries if it's rejected, but I hope that the rejection can come with an alternative solution to the problems with the status quo.
Why?
The current API makes it look like certain operations are possible. However, for some implementations (e.g. dataframes as frontends to SQL backends, polars lazyframes), the following would either have to raise, or trigger an implicit join (a "performance footgun"):
df1: DataFrame
df2: DataFrame
# problematic call:
df1.filter(df1.get_column_by_name('a') > df2.get_column_by_name('b'))

The problem is that the current API makes it look like it should run fine.
What's the suggested solution?
The basic idea is that, instead of only having DataFrame and Column, there will now be 4 classes:

DataFrame
Column
PermissiveFrame
PermissiveColumn

DataFrame
Completely agnostic to execution details (so, some implementations may choose to use lazy execution for it).
Initialisation:

namespace.dataframe_from_dict
namespace.dataframe_from_2d_array
df.__dataframe_consortium_standard__()

Individual standalone columns cannot be extracted. All operations must be done on the dataframe level, using Columns to refer to individual columns.
Column
Can be used to create new columns in a dataframe, update a dataframe's column(s), or filter a dataframe's rows. Examples:
# keep rows where 'a' is greater than 3
df = df.filter(col('a') > 3)

# divide the values in column 'a' by 2
df = df.assign(col('a') / 2)

# insert a new column 'c' which is the sum of columns 'a' and 'b'
df = df.assign((col('a') + col('b')).rename('c'))

Formally, a Column is lazy and is evaluated within the context of a DataFrame.
The idea is that
        df: DataFrame
        col = df.__dataframe_namespace__().col
        df = df.filter(col('a') > col('b')*2)

should behave a bit like (pandas syntax):
        df: pd.DataFrame
        col_a = lambda df: df.loc[:, 'a']
        col_b = lambda df: df.loc[:, 'b']
        col_b_doubled = lambda df: col_b(df) * 2
        mask = lambda df: col_a(df) > col_b_doubled(df)
        df = df.loc[mask(df)]

This has two benefits:

no need to repeat the dataframe name over-and-over again (and this is a common complaint about pandas syntax)
the Column API restricts you to refer to columns from the given dataframe. If you want to insert a column from a different dataframe, you'll need to do a join first.

In particular, this resolves the "problematic call" from the "Why?" section as it would become impossible to write.
Initialisation:

namespace.col
other top-level Column functions (namespace.any_rowwise, namespace.all_rowwise, namespace.sorted_indices, namespace.unique_indices)

Supports all functions on Column, but with the following differences:

reductions (e.g. col('a').mean()) return a length-1 Column rather than a Scalar
there is no to_array_object
no .dtype, as Columns are free-standing. If you want to know the dtype of a DataFrame's column, use DataFrame.schema[column_name]
no name - instead, there are:

root_names: the column names from the dataframe to consider when creating the output column
output_name: the name of the resulting column

Note that Column.len is supported, which (lazily) evaluates the number of rows
PermissiveFrame
Like DataFrame, but must be able to support eager evaluation when evaluating to_array_object. Other operations can stay lazy - if it wishes - but it needs to be able to evaluate eagerly when required.
Initiallisation: can only be done via:

DataFrame.collect()

Supports everything in DataFrame (except collect), but also:

to_array_object (to produce an 2D ndarray)
relax (to go back to DataFrame, which is totally agnostic to the execution mode and so might be lazy in some implementations)
get_column_by_name (to create a single PermissiveColumn)

I've documented that collect should be called as little and as late as possible.
PermissiveColumn
Initialisation:

PermissiveFrame.get_column_by_name
ser.__column_consortium_standard__()
namespace.column_from_sequence
namespace.column_from_1d_array

Just like Column, but:

reductions (e.g. Column.mean()) return scalars
it supports to_array_object (for creating a 1D array)
it has .dtype property
it has name, and no root_names nor output_name

Assorted
shape
I've removed shape as well to discourage df.collect().shape. It's not needed anyway:

if people want the number of columns, they can do len(df.column_names)
if people want the number of rows, they can evaluate that on the Column level, which will stay lazy, e.g. namespace.col('a').len()

If anyone has a use-case for which this is really necessary, we can always add it in again later (adding extra functionality is backwards-compatible)
Column | PermissiveColumn
A PermissiveColumn can be thought of as a trivial Column. For example (pandas syntax) df.loc[pd.Series([True, False, True])] can be thought of as the following Column:
df: DataFrame

def mask(_df):
    return pd.Series([True, False, True])

df.loc[mask(df)]

and so functions which accepts Columns (like .assign / .filter) should also accept PermissiveColumns.

A current goal of the Standard is to have the API be completely independent of execution details. This proposal would slightly relax that goal, so that only DataFrame and Column would be completely independent of execution details

Examples
I've included some examples in the PR, which I think would generally be good to include in the repo anyway to demonstrate how this is meant to be used.
1. center dataset based on mean from training set
Function just transforms a DataFrame, so everything can happen at that level. No need for collect
2. Group-by then plot
Function accepts Series, so PermissiveColumn needs using here
3. Split dataset and train model
In order to train an ML model, conversion to ndarray will have to take place. So,
DataFrame.collect is needed, but it only needs to be called once, after the more expensive calculations have been done
FAQ
Why namespace.col instead of DataFrame.col?
I've stated in https://github.com/data-apis/dataframe-api/issues/244 that I'd like the Standard to feel familiar. Multiple libraries (pyspark, polars, ibis, siuba) already have something namspace.col-like, and so this would feel familiar to their users.
If someone wants the dtype of a column of a DataFrame, they can do df.schema[column_name] (if #248 is accepted)
Why does PermissiveFrame need namespace.col? Isn't that just a lazy thing?
It can work for eager dataframes as well. If plant_statistics is an PermissiveFrame, you can write
    plant_statistics = plant_statistics.filter(
        (col("sepal_width") > col("sepal_height")) | (col("species") == "setosa")
    )

instead of
    plant_statistics = plant_statistics.filter(
        (
            plant_statistics.get_column_by_name("sepal_width")
            > plant_statistics.get_column_by_name("sepal_height")
        )
        | (plant_statistics.get_column_by_name("species") == "setosa")
    )

and maybe there'd be some scope for limited and basic query optimisation in libraries which up until now have been completely eager (like pandas)
Can I try this out?
By the time I mark this as ready-for-review, I'm hoping it will be possible to try out https://github.com/data-apis/dataframe-api-compat/pull/13
Why do we need collect at all? Can't everything be agnostic to execution details?
Please see example 3
Why do we need PermissiveColumn at all?
Please see example 2
See Also
Some related discussions happened at:

#247
#231
#224

Thanks @MarcoGorelli for the detailed proposal + prototype!
Here are some of the bigger picture questions that came to mind:

Should EagerColumn and EagerDataframe be "full" APIs, i.e. a superset of Expression and DataFrame? The alternative would be to keep them limited to things that don't fit into the common subset. I think I agree with your take that it should be a superset, but it seems like that decision could go either way.

example_2.py shows a .collect() on line 31 that's a bit early. You suggested that there could be double computing happening in case it's put at the last possible moment (which is right before the .to_array_object() calls). However, this depends on the underlying engine and how good it is at caching intermediate results. And whether those intermediate results are ever fully materialized to begin with. That example does show a single .collect() call but a fully-materialized dataframe; the alternative would be to use two .collect() calls and only materialize two columns. Which one is better is data-dependent and implementation-dependent. The optimal case would be to have great full-program optimization and zero .collect() calls, but as we discussed that is a huge engineering effort and there are current no dataframe libraries that can actually do this. So practicality beats purity. That said, this is going to require some guidance for users I think.

The expressions are still a little new/confusing to me (and I'm probably not alone in that). One thing that I think is missing is a specific name for "function that returns an expression". There are currently 5 such functions in the API (col, any/all_rowwise and sorted/unique_indices).

It's slightly suboptimal that there's multiple ways of composing the same thing. E.g.: df.select(col('a')).mean() vs. df.select(col('a').mean()). The latter one expresses better what's actually happening in execution order, but the former one is used in the example (and perhaps more analogous to SQL?). When expressions are composed, the semantic order of operations isn't completely obvious. In the example given before in this question, its "select column 'a' from dataframe, then take mean of column". For the .filter((col("sepal_width") > col("sepal_height")) ...) example in the PR description, there's more going on - this is actually nontrivial to write down; the expressions aren't chained but instead there are multiple "select column from dataframe" operations followed by two comparison between columns, then a row-wise selection. What is allowed here and what isn't? E.g. is df.filter((col("sepal_width") allowed when that sepal_width column is not boolean?

More a comment than a question: one thing I learned today from you is how this solves some of the issues around lazy implementations. A key design rule seems to be that there is only a single DataFrame method that takes another dataframe as input, namely .join(). That by design avoids problems with deterministic operations etc. that we identified in previous discussions on other issues/PRs.

Like DataFrame, but must support eager evaluation.

Should it be "must" here? I'd think that any library which can implement this lazily should still be free to do so? The Eager in the name is more a hint that some methods for this column class may need to trigger execution, not that it's forbidden to stay lazy as long as possible and do execute-when-needed? I think that may be what you intended; it requires writing that down explicitly I'd say.

Readability matters.

Please remember that to a large extent this is in the eye of the beholder. To me your preferred version uses both method name and syntax that I don't yet understand and therefore would have to look up. While this, while more verbose, is much easier to understand for me - and arguably also for the average non-initiated reader:
col_width = plant_statistics.get_column_by_name("sepal_width")
col_height = plant_statistics.get_column_by_name("sepal_height")
col_species = plant_statistics.get_column_by_name("species")
rows = plant_statistics.get_rows_by_mask((col_width > col_heigh) | col_species)

Also, the plant_statistics name is unusually long here, so repeating it is an extra penalty on any syntax that repeats the dataframe name. If the variable was named df (or even df_plant) the difference in number of characters wouldn't be nearly as large.
So while I'm not at all opposed to changes to naming for those who have to read it more, I'd keep in mind that this is not at all clear cut and by itself not the strongest rationale for introducing new classes/objects.
That said, I don't think this particular rationale is needed at all here. The stronger rationale is that an expression is nicer to work with as an execution-independent abstraction, so it seems useful and preferable to a separate lazy-only expression object.
Also, it was encouraging to hear that something expression-like may be in the works for Pandas.

Current impression: this is quite promising. There may be some things to clarify regarding semantics, but I like it so far.

Current impression: this is quite promising. There may be some things to clarify regarding semantics, but I like it so far.

Thanks! This is a huge relief, I kind of needed to hear something like that

For the .filter((col("sepal_width") > col("sepal_height")) ...) example in the PR description, there's more going on - this is actually nontrivial to write down

Let's try :) I'll try to write down what: df.filter(col('a') > col('b')) would resolve to

col('a'): lambda df: df.loc[:, 'a']
col('b'): lambda df: df.loc[:, 'b']
col('a') > col('b'): lambda df: (lambda df: df.loc[:, 'a'])(df) > (lambda df: df.loc[:, 'b'])(df)
df.filter(col('a') > 3) : df.loc[(lambda df: (lambda df: df.loc[:, 'a'])(df) > (lambda df: df.loc[:, 'b'])(df))(df)].reset_index(drop=True)

We can try this out with a concrete pandas dataframe:
In [11]: df = pd.DataFrame({'a': [1, 4, 2, 3, 5], 'b': [9,1,4,2,5]})

In [12]: df.loc[(lambda df: (lambda df: df.loc[:, 'a'])(df) > (lambda df: df.loc[:, 'b'])(df))(df)].reset_index(drop=True)
Out[12]:
   a  b
0  4  1
1  3  2

The usual rules would still apply - filtering with something not boolean would still raise

That example does show a single .collect() call but a fully-materialized dataframe; the alternative would be to use two .collect() calls and only materialize two columns

I am indeed materialising the whole dataframe though:

x_train gets all columns except for 'y'
y_train gets only column 'y'

If I was only selecting two columns, then it would have been better to first select those two columns, then collect, and then split. But there would still just be a single collect, and it would have been as late as possible.
I expect the maxim "use collect as late as possible, and ideally just once" it to be close-to-optimal for most cases - counterexamples would be very welcome (and very interesting!)

However, this depends on the underlying engine and how good it is at caching intermediate results

Not sure I see how this would work at all actually, even with infinite engineering resources
Say I do
df: DataFrame
x = df.filter(col('score') > 0).select('a', 'b').collect().to_array_object()

I now have a array assigned to x. Should the underlying library have cached anything when calling .collect()?
It depends.

If I was then to calldf: DataFrame
y = df.filter(col('score') > 0).select('c').collect().to_array_object()

then the optimal thing to do would have been to cache the result of df.filter(col('score') > 0).
But if df was not used again, then the optimal thing would have been to not cache anything.

Problem is, if we're defining a Python API, then we're not in a purely compiled language. And so when .collect is called, we have no idea which of the two scenarios above we are in.

Should it be "must" here? I'd think that any library which can implement this lazily should still be free to do so?

I'll try to make this clearer, thanks.
EagerFrame doesn't need to do everything eagerly, there just needs to be a way to:

get a concrete value for a column reduction
convert to a concrete ndarray

Not saying it needs to do everything eagerly, happy to let implementations figure out the details here - but it does need to have the ability to step out of lazy mode and produce something eager

But if df was not used again, then the optimal thing would have been to not cache anything

That's kind of the same argument as sometimes used against Python garbage collector, but it's a thin one. If df was already allocated, it costs very little to hold onto it until you actually need the memory for something better. Surely a good caching system with the appropriate cache eviction rules will be able to manage memory usage better than manual selection of what to cache and what not.

It depends. [...] And so when .collect is called, we have no idea which of the two scenarios above we are in.

I think this is why PyTorch/JAX/TF (and Numba for NumPy) have "lazy modes" using @jit, torch.compile et al. Then you can know which situation you are in and make the optimal decision. There's a lot of prior art here I'd say.
I'd summarize the decision of using a .collect() as:

it's a way to signal to users that an operation cannot stay lazy, and nudge them to reconsider whether they cannot rewrite their code with a different operation that does allow staying lazy;
if it's not possible to keep things lazy anyway, the .collect() is extra baggage and now forces the user to make decisions about when to explicitly trigger a computation - and in principle they cannot do a job as good as the execution engine itself, because it may well be the case that "cache or recompute" depends on both the shape of the data and the machine's hardware config.

I expect the maxim "use collect as late as possible, and ideally just once" it to be close-to-optimal for most cases - counterexamples would be very welcome (and very interesting!)

I think the "just once" is important, but there's a little more to it - it's not hard to write code that's worse than eager mode would be. In your example_2.py, just reuse df at the end of the function (e.g. return df.std() as a second output), and it seems to me like that will run the expensive_feature_engineering call twice (at least in Polars, since it doesn't cache by default). I think to be "performance-safe", you should write:
eager_df = df.collect()
del df

Either that or do df = eager_df.relax() as soon as you're done with the operations that you needed eager_df for.

If df was already allocated, it costs very little to hold onto it

Sure, but what if it's not been allocated?
E.g. if I did
x = df.select(col('a').sort().head(5)).collect()

then, the dataframe could optimise it to
x = df.select(col('a').top_k(5)).collect()

under-the-hood and never even allocated df.select(col('a').sort()) - so if that part was needed in another computation, it would have to be recomputed

(e.g. return df.std() as a second output), and it seems to me like that will run the expensive_feature_engineering call twice

OK yes, it would if you then called .collect() again on the output
Maybe we can be more precise in the guidance then - only call .collect() once per dataframe. And perhaps even introduce an optional "dataframe API linter" which guards against double-collection on the same dataframe

Sure, but what if it's not been allocated?

If it's never been materialized in memory before there's nothing to cache. But that's not really a counterpoint, it's only a "there wasn't an opportunity to miss here, hence it wasn't missed".

Maybe we can be more precise in the guidance then - only call .collect() once per dataframe. And perhaps even introduce an optional "dataframe API linter" which guards against double-collection on the same dataframe

This sounds like a good rule to me. No need for a linter I'd say - it can be implemented simply by keeping track of an _already_called boolean variable that .collect() can check.

If I write
df: DataFrame
x = df.select(col('a').sort().head(5)).collect().to_array_object(Int64())

then should df['a'].sort() be cached, or should .sort().head(5) be optimized to .top_k(5)?
It depends on what comes next:

if I then wrote y = df.select(col('a').sort().abs()), then it would've been optimal to cache col('a').sort()
if I then finished the function and didn't do anything else with df, then the optimal thing would've been to optimise col('a').sort().head(5) into col('a').top_k(5)

But we don't know which case we're in - and so long as we're defining a Python API, then I don't know how we can.
Anyway, sounds like we're in agreement on just documenting that .collect should be used at most once per dataframe, and as late as possible.

it can be implemented simply by keeping track of an _already_called boolean variable

It would be a bit more complex, as it would need propagating - for example
df: DataFrame  # _already_called is False
x = some_function(df).collect()  # output of some_function(df) gets _already_called True
return df.std().collect()  # allowed, as _already_called on df is still False

In any case, I don't think we can enforce that all implementations add such a flag - but we could make a dataframe-api-linter independently of what implementations do

Anyway, we're getting a bit sidetracked here, and it sounds like we're in agreement on what to do with regards to collect anyway
@shwina any thoughts on this proposal? (no hurry)

The current API makes it look like certain operations are possible. However, for some implementations (e.g. dataframes as frontends to SQL backends, polars lazyframes), the following would raise:

df1: DataFrame
df2: DataFrame
# problematic call:
df1.filter(df1.get_column_by_name('a') > df2.get_column_by_name('b'))

@MarcoGorelli Is this problematic call still possible using EagerFrame and EagerColumn classes? If yes, and, for example, Polars will also implement them, then the problem will remain.

Polars already has an eager dataframe class (polars.DataFrame) from which you can extract eager columns (polars.Series). On those objects, that call has no issue - no, there's no problem here

The call is only problematic for polars.LazyFrame

polars.LazyFrame has join operation, why not do it implicitly when comparing?
P.S. I already see that there were a lot of discussions about lazy calculations, quite easily I could have missed the discussion of the question that I asked, sorry for that and if there is anything you could just post a link to the right discussion (if it's more convenient).

That would be a performance footgun:
In [1]: df1 = pl.LazyFrame({'a': np.random.randn(100_000_000)})

In [2]: df2 = pl.LazyFrame({'a': np.random.randn(100_000_000)})

In [3]: %timeit _ = df1.filter(pl.col('a')>0).collect()
146 ms ± 1.85 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [4]: %timeit df1.with_row_count('idx').join(df2.with_row_count('idx'), on='idx').filter(pl.col('a_right')>0).drop('a_right', 'idx').collect()
821 ms ± 33.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

PS. no worries, I don't think there's an existing discussion with this question (but it might have been asked during the latest call - recordings are at https://github.com/data-apis/workgroup/issues/10, let us know if you need access)

That would be a performance footgun:
In [1]: df1 = pl.LazyFrame({'a': np.random.randn(100_000_000)})

In [2]: df2 = pl.LazyFrame({'a': np.random.randn(100_000_000)})

In [3]: %timeit _ = df1.filter(pl.col('a')>0).collect()
146 ms ± 1.85 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [4]: %timeit df1.with_row_count('idx').join(df2.with_row_count('idx'), on='idx').filter(pl.col('a_right')>0).drop('a_right', 'idx').collect()
821 ms ± 33.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

PS. no worries, I don't think there's an existing discussion with this question (but it might have been asked during the latest call - recordings are at data-apis/workgroup#10, let us know if you need access). Overall, please do feel welcome to ask all the questions you'd like! 🙏

What if something like this:

def __gt__(self, other):
  if [some condition that check `self` and `other` from different dataframes]:
    result = self.join(other)
  [comparison implementation]

In the case where the columns do not require a join, the function is still as fast as before (unless the condition requires a lot of computational resources). In the case where a join is needed, we will execute it implicitly in the function (without forcing the user to execute it explicitly before the comparison function). In some situations this may be extremely ineffective, but for this purpose we can provide a warning mode (off by default), which can warn that an implicit join is being made and that it may make sense to do it explicitly in order to reuse the result. This way the code will remain more attractive/familiar for beginners, but there will be hints (via warnings) on how to write the code more efficiently. However, I don’t know whether the use of warnings can be documented in the standard in principle.
Or prohibit (for all implementations) the operation of comparing columns if there is a need to join them before. A more strict solution, but still simple. It is very likely that this was also discussed somewhere (it would be great if this pull request had a link to the outcome of this discussion)

I like your idea in terms of flexibility regarding possible optimizations, but I worry that new entities and relationships between them greatly increases the barrier to entry for new users/developers. Have you considered adding new (lazy) methods to existing entities of DataFrame API?

Thanks for your suggestion - it's true that we could do that, but I'd like to make the case that we shouldn't
The whole "it's fast in some cases and painfully slow in others and I have no idea why" thing of pandas is a common pain-point for users - for example, can you guess which of series.apply(np.sin) and series.apply(lambda x: np.sin(x)) will be faster? (OK, you probably can, but most users can't 😄 )
In general, the Consortium is serious about avoiding performance footguns (e.g., https://github.com/data-apis/dataframe-api/issues/131#issuecomment-1496869891, forbidding iterating over the elements of Column, not sorting by default in group_by)
If filtering one dataframe by another ends up being a common use-case, then we can always consider allowing it later on - but it's much easier to start strict and relax later on than to do the other way round

Have updated, and done some renamings as discussed last time
cc @jorisvandenbossche in case you have an opinion here (getting this right here will help sort out some issues with pd.col before we try to get this into pandas itself)

I think the "just once" is important, but there's a little more to it - it's not hard to write code that's worse than eager mode would be. In your example_2.py, just reuse df at the end of the function (e.g. return df.std() as a second output), and it seems to me like that will run the expensive_feature_engineering call twice (at least in Polars, since it doesn't cache by default). I think to be "performance-safe", you should write:

A real-world example that would take advantage of "cached" results would be our ONNX-based implementation. Consider the following (pseudo-code) example:
# Construct a lazy data frame.
# The input columns are of type int64 and will be provided as user input at inference time
df = lazy_standard_df_from_user_input({"a": "int64", "b": "int64")
features = expensive_feature_engineering(df)
std = features.std()

# Build the ONNX model
model = build_onnx_artifact(inputs=df, outputs={"features": features, "std": std})
import onnx
onnx.save(model, "my_model.onnx")

Running this ONNX model with user provided input will run the feature engineering step only once in order to produce features and std.

Thanks for the very fruitful discussion we just had! I'd like to provide an example that illustrates how function signatures of the current proposal can be used to indicate that functions require eager implementations, but not to signify that they are compatible with lazy implementations.
Let's consider the eager case first:
def do_things(df: PermissiveDataFrame) -> PermissiveDataFrame:
    ...

A function of this type would make it very clear that whatever happens inside it may requires eager computation. This is fine since some tasks such as plotting or fitting a model are usually inherently "eager".
However, the current proposal would also allow the following implementation:
def do_things_sneaky(df: DataFrame) -> DataFrame:
    return do_things(df.collect()).relax()

This is rather unfortunate for two reasons:

It is unclear if do_things_sneaky works with a standard compliant lazy implementation until the user actually tries to call it
Even if do_things_sneaky works today, it wouldn't be a (obvious) semver breaking change to break it for lazy libraries with the next batch release.

Might it be possible to have an inheritance-based solution where PermissiveDataFrame inherits from DataFrame rather than allowing the user to switch back and forth? Both PermissiveDataFrame and DataFrame may still have a way to hint to the underlying implementation that a collection may be in order.

Thanks for your comments and discussion @cbourjau , really productive and helpful!
From yesterday's call, I think (please correct me if I'm wrong) that we're in agreement that there needs to be a way to say "values need materialising" - the onnx-based dataframe case, you'd be able to use that to determine whether:

you can keep the whole graph lazy and export it to an onnx model
you need to materialise some values to pass them to a 3rd party library

An example of when the latter is needed could be fitting an xgboost model (or indeed, as of 2023, any ML model...I'm not aware of any library which can train a lazy model with a lazy array, but please do correct me if I'm wrong).
.collect is here to try to address that second need - and it should only be used in those cases. Anything else should just use the DataFrame (execution-agnostic) API, and a library like your onnx-based dataframe could export the whole thing.

Might it be possible to have an inheritance-based solution where PermissiveDataFrame inherits from DataFrame rather than allowing the user to switch back and forth?

This is a good point. Would just removing .relax from PermissiveDataFrame have the same effect? If so, maybe we could just go with that.
If someone needs to create a DataFrame, they can always use the namespace.from_* constructors

Do you have any thoughts on the namespace.col syntax?

From yesterday's call, I think (please correct me if I'm wrong) that we're in agreement that there needs to be a way to say "values need materialising" - the onnx-based dataframe case, you'd be able to use that to determine whether:

you can keep the whole graph lazy and export it to an onnx model
you need to materialise some values to pass them to a 3rd party library

Technically, the ONNX standard does have provisioning for training, but I'd say it is out of scope. I have never used it, but I think it would essentially require the Array/Dataframe API to standardize training functions such as def train_glm(X: Array, y: Array) -> Array: ....
Eitherway, your takeaway is correct. It would be great if it were possible to differentiate those two points by looking at a function signature.

This is a good point. Would just removing .relax from PermissiveDataFrame have the same effect? If so, maybe we could just go with that.

Going from PermissiveDataFrame to DataFrame is not an issue for our use case. Any function that takes a lazy DataFrame may also accept PermissiveDataFrame objects as far as I can tell. The other direction is the issue for us. I'd love a type hint that signals: "Whatever happens in this function cannot require any eager computation".

@cbourjau just to clarify - would a type hint suffice, or would you need it to be a different at runtime?
I'd really appreciate it if you could contribute an example to the repo (https://github.com/data-apis/dataframe-api/issues/281) of some functions you'd envisage people using the API for - I'm particularly interested in examples you may have of functions for which your library (what's it called, btw?) could stay completely lazy and have everything exported at the end

Thank you @MarcoGorelli for the exploration. Admittedly, it is daunting to review a 2000+ line PR and I have not done a line-by-line review. It's my fault for not following this PR more closely since its earlier iterations.
That being said, thank you for the details in the PR description - it does help understand the motivation behind this change, and gives a good idea about the implementation.
While I can see how the changes introduced here solve the problem posed, I do feel they negatively impact the complexity and teachability of the standard.
From a cuDF perspective, our long-term hope is not to maintain a plethora of APIs (native, standard DataFrame, standard PermissiveDataFrame), but rather a single API that looks more and more like the standard over time. I worry that introducing lazy semantics into the standard will make that increasingly difficult/impossible.

No worries if it's rejected, but I hope that the rejection can come with an alternative solution to the problems with the status quo.

I am more than appreciate and awed at the effort that has gone into this solution, so I do not suggest an alternative lightly:
The goal is to disallow operations between columns originating from different DataFrames, a la Polars. As you say, it can be a performance footgun.
Are folks open to simply saying that the operation is undefined by the existing standard? Implementations can choose to raise. The "blessed" way to do this would be:
lhs = column_from_1d_array(df1.select("a").to_array())
rhs = column_from_2d_array(df2.select("b").to_array())
df.filter(lhs > rhs)

It closes no doors for anyone and allows eager implementations to remain relatively untouched.

Thanks for your feedback

The "blessed" way to do this would be

This wouldn't quite work, df1.select("a") returns a Dataframe, not a Column

Ah, right you are. I meant get_column_by_name

rather a single API that looks more and more like the standard over time

Just for my understading, are you expecting that future cuDF syntax will look like this
    lineitem = lineitem.assign(
        [
            (
                lineitem.get_column_by_name("l_extended_price")
                * (1 - lineitem.get_column_by_name("l_discount"))
            ).rename("l_disc_price"),
            (
                lineitem.get_column_by_name("l_extended_price")
                * (1 - lineitem.get_column_by_name("l_discount"))
                * (1 + lineitem.get_column_by_name("l_tax"))
            ).rename("l_charge"),
        ]
    )

even though pandas (main namespace) won't*?
*it's not my decision. You're welcome to propose this to pandas, I just though it would be right to give you a heads up that this is almost certainly going to be unanimously rejected by other pandas devs, please don't shoot the messenger

The goal is to disallow operations between columns originating from different DataFrames

There's more to it than that:

column reductions
if/when to materialise (see conversation above with @cbourjau - would a function stay completely lazy and be exported to onnx, or would some values need materialising because some library needs them now?)
not needing to compute things more times than necessary when filtering

Are folks open to simply saying that the operation is undefined by the existing standard? Implementations can choose to raise.

I'm open to that. In fact, I'd suggested it here #224 , but the question went unanswered

Just for my understading, are you expecting that future cuDF syntax will look like this

There's no reason cuDF couldn't introduce the get_column_by_name method without keeping its nice getitem interface. The end user would use the latter. Third party library developers who care about cross library compat could use the former.

Apologies for the delayed reply! I had some very busy days! I created a PR with an example of how we envision using lazy ONNX-based data frames to trace inference logic in sklean-like pipelines.
Concerning the previous discussion, I hope that that example may illustrate the benefits of an API that could signal that the tranform methods are guaranteed to not require a collection. I don't have a good solution at the moment, but I hope that this discussion may be the seed of a future one!

Just a brief comment, since it's really tricky to collect (pun intended) and express all my thoughts. First, this is a hard and complex topic, and I think closing this PR was a bit abrupt and probably premature. There's a desire to move ahead and perhaps some time constraints to get to a "ready to adopt" state, but this is the single most difficult design topic so far, so we should be ready to spend a bit more time here. I don't want to hit the "reopen" now, but we should discuss and disentangle things here. Leaving this unresolved and then putting it in some of the library-specific implementations or compat layer isn't going to help us in the long run.
There are at least 3 different topics here:

Syntax preferences. There's a focus on get_column_by_name (continued in gh-287), but there are others. It's a conciseness vs. explicitness thing. I think this is the easiest one to resolve, and most folks are roughly aligned I think. Syntax / method naming is unrelated to lazy/eager.
Execution "hints" vs. being prescriptive. We should be clear that, whatever we add here (if anything), these are hints that individual libraries may use as execution triggers, but they don't have to. The ONNX examples reinforced that point.
Conceptual design. This is the hardest point. There's significant tension here between lazy implementations and eager ones. I don't think we have a solution yet that everyone is happy with. It should be possible to find one though, the differences aren't small, but also not insurmountably large.

My point of view is that we can resolve (1) and (2) quickly, and then with those distractions gone it may be easier to focus on (3).

Thanks for your comments

My point of view is that we can resolve (1) and (2) quickly

How do you propose to resolve (2) quickly?
The use-case I'm particularly interested in addressing is the same one Christian had brought up - you need to materialise data for fit, but can stay lazy for transform / predict

you need to materialise data for fit, but can stay lazy for transform / predict

None of those are actually in this API. What is happening there is that fit is going to be an iterative algorithm, which is going to calculate some loss metric that is being optimized. So what it's going to boil down to is a some_scalar_metric > something_else - and at that point, the Python float you need is the one thing that cannot be kept lazy. Hence that is the place where an ONXX-based (or any maximally-lazy) dataframe implementation will raise.
All this is fully compatible with .collect being a hint rather than an execution directive.

Would it be acceptable to add .collect and explicitly note that it's to be interpreted as a hint, rather than as an execution directive? If so, then together with https://github.com/data-apis/dataframe-api/pull/298#issuecomment-1781587287, then we may have a solution here


greeter-card observers

Hi,
I just get started with Polymer, so this question may seem naive.
I found that Line 81 in the greeter-card.html is confusing to me:
observers: ["reload(run, tag)"],
I guess here it tries to call the member function in Line 94:
reload() {
        if (!this._attached) {
          return;
        }
        this._canceller.cancelAll();
        const router = getRouter();
        const url = router.pluginRunTagRoute("greeter", "/greetings")(
          this.tag, this.run);
        const updateData = this._canceller.cancellable(result => {
          if (result.cancelled) {
            return;
          }
          const backendData = result.value;
          this.greetings = backendData;
        });
        this.requestManager.request(url).then(updateData);
      }

It seems like the parameters do not match here. There is no parameter for the function definition, while when observers tries to call this method, it passed run and tag, the public member properties of this Web  component. I am wondering if this is problematic.
BTW, I tried to change Line 91 to:
observers: ["reload()"],
It still works for this simple demo.

Any suggestions? Thanks!

@BinhangYuan, sorry for missing this.
The list of observers specifies what parameters are being observed, in this case run and tag. Hence, every time either run or tag is set, the reload method is run.
You are correct in that the definition of reload accepts no arguments. The best practice would be to use reload(run, tag) (which I will fix in a pull request). However, the logic as written should still work.
Removing the parameters from instance in the observers list probably breaks behavior because the reload method won't be called when either the run or tag properties change.
Thank you for reporting this issue!


LaTeX blocks

This adds support for blocks in the LaTeX output.
The main latex code is in latex/macros.tex. Like all latex code it is just the worst, most horrible code in the world doing the most horrible things. (1 point for \csname, 1 point for \expandafter.) I assure you I refactored it before PRing.
The main Lua code is in Div at the end, but many many other random Lua changes were necessary because we now don't want any blocks in the LaTeX code except the blocks we care about. (If this becomes burdensome we could do an allowlist of blocks instead of a denylist.)
Also added support for hyperlinks (easy).
Here's what it looks like:

Colors are configurable but I sorta tried to match the website.

I'll look into turning hyperlinks into endnotes later.

Or perhaps the publisher can deal with endnotes.

Looks like this broke outlines in the web version.

That was a challenging bug to fix (I had to learn a lot of Lua and a lot more about Pandoc) but I think it is fixed now.

I do love that "make colored boxes in a PDF file" ends up being harder than, like, "add clip compositing" or whatever to the browser :)


[feat]  Create a new stand alone binary of the "Debug window"

Greetings
In Dogecon-qt the Debug windows is really nice and easy to use to see how dogecoin-qt "service" is doing. However, when running dogecond as a service, dogecoin-cli does provide the abillity to pull out json data about how the service is doing.
Basically, I'm running a very slim Unix on a powerful server using dogecoind. I would like to have a gui version of Windows dogecoin-debug to connect to the unix server to see how it is doing.
For now I'm pulling out the info I need/want and parsing the data in a script so technically low priority.
However, I'm hoping all the code is there so it's a matter of repackaging a new "main" and compile.
Ps. Thanks for 1.14.4. Easy to run and runs nicely.

However, I'm hoping all the code is there so it's a matter of repackaging a new "main" and compile.

Unfortunately (or fortunately, depending on perspective 😁) the debug window currently hooks straight into the internal state that the rpc also uses, rather than using the rpc to fetch the data, so that would need to be re-coded. Also, as this would require RPC access and the RPC doesn't have real secure authentication mechanisms (it's really intended to be bound to local interfaces only) there would be some security concerns.
As an alternative, there used to be some Grafana based dashboard integrations that would basically pull the stats from your dogecoind, persist it and then expose some very nice looking graphs via HTTP. I know that some shibes that are subscribed to this repository are using it, perhaps they'd like to chime in about what they use?


print pdf

how print the pdf

Hi @sidahmedbenkhaoua,
at this time it isn't possible, but a pull request is welcome!

@sidahmedbenkhaoua isn't possible print the pdf, but you can use window.print() to print the page.
To exclude other element you can use css's @media print.
Let me know!

Can someone suggest an angular gem for printing pdf?

@KranthiKishore please, next time open an other issue, and open issue related to this package.
Gems are Ruby package, angular is JavaScript package.

@simobasso Sorry for that and Does this package supports pdf print?

@KranthiKishore at this time isn't possible print the pdf, but you can use window.print() to print the page.
To exclude other element you can use css's @media print.


SOLR-17126 Cut over System.getProperty() to EnvUtils for modules (backport-9x)

https://issues.apache.org/jira/browse/SOLR-17126
This is a backport of #2193. Some differences in modules like OpenTelemetry caused some manual steps.
edit Gave it a new JIRA issue number, targeting 9.6

https://issues.apache.org/jira/browse/SOLR-17126


Broken link in search

When searching a word on the readthedocs.io, the result links are broken.
Example:
The result of "communicator":
http://chainermn.readthedocs.io/en/latest/search.html?q=communicator&check_keywords=yes&area=default
The first result is:
http://chainermn.readthedocs.io/en/latest/reference/index.rst.html?highlight=communicator
This is because the extension (.rst.html) is wrong, but simply ".html" is correct.

It works with locally-generated HTML. Hmm

Seems to be this issue: https://github.com/rtfd/readthedocs.org/issues/2708


Unable to start cloud controller workers after restore

Using v2.0.53
From /var/vcap/data/sys/log/cloud_controller_worker_ctl.err.log on cloud controller worker partitions:
[2016-01-30 02:36:54+0000] ------------ STARTING cloud_controller_worker_ctl at Sat Jan 30 02:36:54 UTC 2016 --------------
[2016-01-30 02:36:54+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2016-01-30 02:36:54+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2016-01-30 02:36:54+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2016-01-30 02:36:56+0000] rake aborted!
[2016-01-30 02:36:56+0000] Sequel::DatabaseError: PG::InvalidSchemaName: ERROR:  no schema has been selected to create in
[2016-01-30 02:36:56+0000] PG::InvalidSchemaName: ERROR:  no schema has been selected to create in
[2016-01-30 02:36:56+0000] Tasks: TOP => jobs:generic
Seeing the following error repeated in the postgres log for ccdb as well as a similar error for uaadb:
2016-01-30 02:05:02.413 GMT: STATEMENT:  CREATE TABLE "schema_migrations" ("filename" text PRIMARY KEY)
2016-01-30 02:05:02.559 GMT: ERROR:  relation "schema_migrations" does not exist at character 27
2016-01-30 02:05:02.559 GMT: STATEMENT:  SELECT NULL AS "nil" FROM "schema_migrations" LIMIT 1
2016-01-30 02:05:02.560 GMT: ERROR:  no schema has been selected to create in

Can you send over some information so we can help dig a bit on this issue:

version of cfops
version of PivotalCF (both before and after restore)
steps and command ran as part of the restore process
ER persistence configuration (mysql, postgres)
what command yielded the above error?

thanks

CFOps version 2.0.53
PCF version: 1.6.4 (before and after restore)
Restore steps:
I first deployed a new ops manager to an empty cluster (same ops man version as the one from the backed up platform) and ran the cfops restore command for the ops-manager tile. This completed without error and following that I clicked "Apply Changes", which also completed successfully. Then I ran the cfops restore command for the elastic-runtime tile which also showed no errors:
LOG_LEVEL=debug ER_VERSION=1.6 ./cfops restore --du "pcfadmin" --dp "***" --omu   "ubuntu" --omp "***" -d ~/backup_gtdcdev002/ -t "elastic-runtime" --omh "x.x.x.x"
ER is configured to use postgres for ccdb, uaadb, and consoledb

The above errors appeared after trying to start the cloud controller/cc workers. The bosh start <cc_job> and bosh start <cc_worker_job> commands I ran failed after a timeout period, and I investigated by ssh'ing to the cc worker vms and noticed the first error in the error log repeated - it kept trying to start the cloud controller worker and failed each time. I ssh'ed to the ccdb vm and noticed the second error in the /var/vcap/sys/log/postgres/postgresql.log, and a similar error appeared in the postgresql log on the uaadb vm. The consoledb had no such error in the postgres logs.

the cc jobs should be stopped/started by cfops. what is the context in which we need to run bosh start or interact directly with bosh?
just trying to connect all the dots so i can more reliably reproduce your environment. let me know, thanks.

Well, I noticed after running cfops and waiting a while the cc jobs were still in a failing/starting state. I tried to start them manually to see what was preventing them from starting.

Closing this issue
see https://github.com/pivotalservices/cfops/issues/55 for root cause.


Search matches characters across new lines

Just observing this with the default tracemonkey paper.

Use the Find tool and enter "na" in the search box. Check the "Highlight all" box.
Scroll down to page 2 of the paper, and see the 3rd paragraph. It highlights the "na" in "In a", which is across a new line.
Change the search query to "andt" and you can see it highlights "andt" in "and the".

Seems it needs some sort of checks to ensure that search will not return these results?

+1
Problem is actual.

Search results are incorrect due to this problem.
Would be considered this issue?

A similar problem is solved in #5783.

I know this is an old thread, but anyone knows if this is issue was solved?
I'm having the same situation where the search finds 'words' across new lines, and I tested with versions 1.9.426 (stable) and 2.0.550 (press  release) and the issue persists.

It's partially fixed thanks to https://github.com/mozilla/pdf.js/commit/af4dc55019efd82cdb002dc25901d6d113406ebe which helps to detect EOL.
And this PR: https://github.com/mozilla/pdf.js/pull/13261 should definitely fix the problem.


Dependency pdoc3 has incompatible AGPL license

Hi again!
Currently pdoc3 is a required dependency however it carries the AGPL license. This dependency is packaged as MIT and is therefore easily integrated in other applications but AGPL has widespread consequences for users of Streamcapture. Therefore, I propose to move pdoc3 to the 'extras' requirements as pdoc3 is not required to run the code but rather as a development tool and so we can keep the MIT license for Streamcapture.

I've merged the thing you said so I guess I'm closing this?

Thank you for closing the issue, this is perfect!


Binding Incompatibility with PR 503  - New Tag v.1.25.2

Added an incompatibility with PR https://github.com/abap2UI5/abap2UI5/pull/503
Now:
Variables which are binded with _bind always have to be public attributes of the app class. Otherwise an error is thrown.
Before:
If _bind was used with a non-public attribute automatically one time binding with the actual value of the variable was made and no error occured.
Check this for an example:
https://github.com/abap2UI5/abap2UI5-samples/blob/131f800419618547488dd0c4af70d36d2176697e/src/z2ui5_cl_app_demo_02.clas.abap#L166
Need the version before this change?
Use this tag: https://github.com/abap2UI5/abap2UI5/releases/tag/v.1.25.2

is something wrong with the binding ??
demo 97 acting weird, but the code seems to be ok..

ah yes thanks for the hint. seems there are still some issues. started to fix it and it is working now but i need to test it more. you can check _dev branch if you need it quickly or use the tag.

great. just implementing new features and saw the binding not working correctly

updated the demo 102 with your code and fixed some bugs with the binding.
i can not find any entries with this demo:

its case sensitive i fell for that also :)

but it is working now on my side:

Updated the name of the http handler with the latest commit.
Before:
z2ui5_cl_http_handler
Now:
z2ui5_cl_fw_http_handler

Updated the name of the http handler with the latest commit.
Before: z2ui5_cl_http_handler
Now: z2ui5_cl_fw_http_handler

does this changes something ??

no, just adjust your http handler with the new name.

manually ? or pulling latest pr ?

Pull latest PR but the call of the http handler is in your custom http handler. There you have to do the adjustment manually.

Pull latest PR but the call of the http handler is in your custom http handler. There you have to do the adjustment manually.

oh thats right !! thanks

btw.
also added the feature that you can now add your own javascript to the index.html (if needed):
https://github.com/abap2UI5/abap2UI5/blob/main/src/z2ui5_cl_fw_http_handler.clas.abap#L18

wow !
like creating a function and use it via expression binding ??

yes this is for example an option.

@oblomov-dev
how can we call a function in the custom_js property, from abap and not with expression binding ??

You can call it for example like this:

Great! thx !

yep it is added now.

seems not to work when trying to call it in a popup
see demo..
demo_90.txt
im trying to implement P13N.POPUP control.. (the new one)
but the data loading is from js only..
this is what i inserted into custom_js function in the handler..
custom_js.txt

Just took a look to the source code without starting it, but maybe the following helps:
It looks like you want to reference UI5 objects in your new method, but you call this method during rendering and i think it is to early because the ui5 controls are not created at this time. You can call this method with a timeout just to see if it is working then. Or what is your error message?
Why are you not creating a custom control to fill the p13n data with JS like you did with the spreadsheet for example?

well i think custom control is a bit overkill for this scenario.
i didnt say the the zcc_plain_xml line was workibg and triggering the js code once inserted in main xml view and not a fragment.
i liked the approach you said triggering it with timeout,
how i do that? as far as i understand i need somekind of view to trigger a js function no?

Ah ok it is just not working in a fragment? Then my guess was wrong. Can you also give me the working snippet when you put it into the main view? Then I can compare both and check if I find something.

its just to change to view type from view to popup..
ill send it later today,
but i think this still will not work as the zcc_plain_xml trigger the js function before the popupview is loaded, like you mentioned before.
as in the js function i need to get the object byId from the popupview

@choper725 create a new issue for your problem, i will close this one, that the topics don't get mixed.