text:
Transitime open source transit software

[ Great find by @greenlinktransit, starting new issue ]
This could have been used for our Trolley Tracker, but we'd have to trade off by adding complexity of working with GTFS for route and stop definition and give up some of our custom features.   ( I haven't found any open source GTFS editor that's reasonably useful - there are some commercial GTFS editors though)
That being said, this application would be very applicable to the rest of the city buses as a way to add vehicle tracking to assist Greenlink dispatch and riders.   It requires a full GTFS dataset for maximum usefulness, along with a beacon and data interface per vehicle.  I can't see that it has further AVL functions such as cash box interface and passenger counting by stop, etc, but those wouldn't be too difficult to add onto the base software package.

For quick reference:

Main web site http://www.transitime.org
Award http://devpost.com/software/transitime-open-source-real-time-transit-information
Code https://github.com/Transitime/core

For what it's worth, I have Greenlink's GTFS file for all of the normal fixed routes.  Hoping to build the Clemson routes in the near future.  Getting the Trolleys on GTFS is difficult because GTFS requires timed stops, which the Trolley does not have.

source: gharchive/issue

authors: bikeoid greenlinktransit

repo: codeforgreenville/trolley-tracker

license_type: permissive

license_source: bigquery


text:
nuxt-firebaseに変更

改善詳細 / Details of Improvement

xxxx(できるだけ簡潔に/as concise as possible)

スクリーンショット / Screenshot

期待する見せ方・挙動 / Expected behavior

xxxx(できるだけ簡潔に/as concise as possible)

動作環境・ブラウザ / Environment

macOS / Windows / Linux / iOS / Android
Chrome / Safari / Firefox / Edge / Internet Explorer

#43 で導入し #49 でリバート
リバート理由は https://github.com/codeforjapan/StudyAtHome/pull/49#issuecomment-629932000 を参照

repo: codeforjapan/StudyAtHome

license: MIT

license_source: github-api


text:
Add area detail under zone number

I added area detail under zone number according to this issue https://github.com/codeforthailand/election-live/issues/146.
Screenshot

Thanks!
Please add your name to https://docs.google.com/spreadsheets/d/1r3YDk8CAB6mtAyEJxUBPLgjW0Baqs6PWUDjcJDG5Juk/edit?usp=sharing as well. The list will be shown on /about.

source: gharchive/pull-request

authors: NesChaiyapon heytitle

repo: codeforthailand/election-live


text:
fix #2 update /api/case endpoint

Changes included in this PR are:

Restrict request method to only GET
Return proper error message when no case is found
Return proper error message when case is found but no arraignment event exists

Blocks https://github.com/codefortulsa/courtbot-python/pull/5

repo: codefortulsa/courtbot-python

license: ISC


text:
Fixed a problem with not run escape for identities in like when insensitiveSearch is true.

Fixed a problem with not run escape for identities in like when insensitiveSearch is true.
Description
Items that can be escaped are not escaped.
Even if the escape flag is true or null, there is no escaping process in place.
This has been fixed so that escaping will be done.
link: #2487
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPdocs
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

Sorry, this PR introduced the bug #5360.

authors: kenjis ytetsuro


text:
Skip hostname checks if CURLRequest options 'verify' is set to false.

When CURLRequest options 'verify' is set to false, some CURLOPT_SSL_... options should be disabled in such a way as to allow requests to pass through in case the destination is for example on private networks.

Description
Explain what you have changed, and why.
Checklist:

[ ] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[x] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

Thank you for sending a PR.
But some checks were not successful.
Please fix the code to pass all checks.
First of all, you need to sign your git commits.
https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md#signing

I will redo this PR.

authors: NicolaeIotu kenjis


text:
fix: shield:user create does not assign a default group

Description
Supersedes #999
Fixes #998
The user registration form sets the default group value for the user when a new user is registered.
But the command shield:user create does not set the default group.
I think we should fix the inconsistency as a bug.

What do you think about reading the available roles from the config file and presenting that as a required choice to the user? https://github.com/codeigniter4/shield/pull/999#issuecomment-1890845904

It would be nice, but nobody has implemented it. It can be implemented as enhancement later.
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

Oh, I have not read the comment carefully. Thanks.
And @bgeneto suggested -g option instead of showing groups and the user interaction. https://github.com/codeigniter4/shield/pull/999#issuecomment-1895726347

suggested -g option

I like this because of less user interactions.

I sent a PR to implement -g option:  #1164

authors: datamweb kenjis


text:
feat: add shield:model command

Supersedes and closes #491

UserModel instead of MyUserModel seems better for the default sample.
There is no need to prefix My.

Oh, I get an error if I specify UserModel. It's a bug.

It's a bug.

@kenjis waiting for you. Did your worries go away?

authors: datamweb kenjis paulbalandan


text:
Fix currency_value_class_info error

Fixes #66
Originally the method was passed as a string to the if condition.
This is equivalent to passing the method itself rather than using
the result of the method call in the if condition.
When adding support for Rails 5, the string was replaced with the
method call which caused the bug. This has been replace with a lambda
which represents the method itself rather than the result of the method
being called.

can this be merged? running of the pr branch now. Works but not indefinately

Can we release this :pray: I don't love to get gems from git :(

authors: Oldharlem ezr-ondrej thegeorgeous

repo: codemancers/invoicing


text:
Firefox Android does not fire key events for backspace

And as such completely breaks CodeMirror's handling of that key
Tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1104817 , and apparently https://bugzilla.mozilla.org/show_bug.cgi?id=1112212 should end up fixing this soon-ish.

The corresponding Firefox bug was fixed a few months ago.

repo: codemirror/CodeMirror


text:
Newline/editing bugs in Android Browser

One problem is that you cannot easily delete newlines. Backspace doesn't work, but you can delete them as part of selection (shift-arrows or long-touch and high-precision dragging).
Another is that if you mess with this deletion for a bit, sometimes editor starts adding a newline for every character you type. I think that internal invisible input area can get a newline stuck in there.
This one happens in Android Browser coming with the OS
Don't confuse 'Browser' with Chrome mobile. Browser comes with Android open-source platform.
This 'Browser' thing reports itself as Chrome 33.0.0.0 in navigator.userAgent, so it's probably uses older cut of the Chrome under the hood.
However that Browser is a widespread app. And it probably closely matches WebView used to embed browser in other Android apps. So it really is a noticeable usage share.
Also see #3653 Arrow keys hide keyboard - Chrome mobile 46

Experienced same behavior, were there no solution for this? I've experienced this issue with unexpected newlines when entering text(if you pause and enter new symbol. newline appears before new input), but second was fixed by disabling "active-line" addon.

@burdiuz Are you seeing the issue in Chrome or in the 'Android Browser'. As far as I know 'Android Browser' has not been on life support since 2013, and Google is trying to get people to switch to Chrome, so I'm not really seeing the stock browser as an important target anymore.

I was trying to find the source of a problem that made editing on Android (in Chrome) completely impossible.  Newlines added all the time, the keyboard closing as I type, backspace not working as expected, really, it was too many issues to count.  I removed all of the options other than mode and theme and then systematically added back one option at a time and redeployed my application and tested.  It turns out that the active-line addon was the source of all my pain.
I am using the mode: 'javascript'.  I am not seeing all of the strange behavior I was seeing in my environment in the active-line demo (https://codemirror.net/demo/activeline.html), but there is some strange behavior in that demo on Android as it is.
Hope this helps others...

I see exactly all the issues mentioned by @swill on Android Chrome. But even removing active-line plugin doesn't fix it. Infact the issue is same on this CodeMirror demo -> https://codemirror.net/demo/theme.html

Yay, I found the issue GitHub's having.

This is a issue that's difficult to debug and would probably require a lot of work to fix.
We are working on a rewrite (CodeMirror 6) that will hopefully address this issue, and we are currently raising money for this work: See the announcement for more information about the rewrite and a demo.
Note that CodeMirror 6 is by no means stable or usable in production, yet. It is highly unlikely that we pick up this issue for CodeMirror 5, though.

Thanks for updating @adrianheine 👍

Just a heads up, this issue appears in chrome mobile as well, regardless of the version as far as I'm aware.
It also has a bit different behavior depending on used keyboard - code comes back all the time on samsung keyboard and it only comes back after removing all the code/stopping delete press on gboard.
We've tried many hacks but with no success. Has anyone figured that out?

We experience a similar error in CodiMD in Firefox on android (see link above). We also came to the conclusion that some keyboards work while others don't.

'the' current (soft) workaround for Android users is to download Keepass2Android and use its keyboard.

—https://github.com/hedgedoc/react-client/issues/437#issuecomment-572646473

'the' current (soft) workaround for Android users is to download Keepass2Android and use its keyboard.

—https://github.com/hedgedoc/react-client/issues/437#issuecomment-572646473

(The CodeMirror 6 beta is quite stable now, and should provide much better Android support.)

(The CodeMirror 6 beta is quite stable now, and should provide much better Android support.)

authors: 0joshuaolson1 AdamZaczek DougInAMug adrianheine burdiuz ccoenen chinchang marijnh mihailik swill


text:
cursor invisible on empty lines in chrome 62

Cursor is visible in lines with some text, but invisible for blank lines. This fixes it:
.CodeMirror-cursor {
	width: 1px !important;
}

I don't see this happening on Chrome 62 Linux. Do you see it on the demos on the website?

Yes, also on demos on the website. But only seem to happen on OS X for certain page-zoom factors < 1 (for example page zoom 80%).

I had the same problem with my cursor at the beginning of a line, the css code of @kay999 fixed it!
thx!

Is this issue still present in Chrome > 62?

@adrianheine, I confirm this issue on Version 67.0.3396.99 (Official Build) (64-bit)

At a small enough zoom level (50%) I can reproduce this. Our cursor is an element with a 1 pixel border, and it appears that at some point Chrome just rounds that down to zero (not just on empty lines, also in some -- but not all -- other positions).
So that's unfortunate, but I don't know how to work around it without making the cursor fatter in all circumstances (which isn't desirable).

This is one of many issues which are difficult to solve with the fundamental approach currently taken by CodeMirror.
We are working on a rewrite (CodeMirror 6) that will overhaul input handling and should address this issue, and we are currently raising money for this work: See the announcement for more information about the rewrite and a demo.
Note that CodeMirror 6 is by no means stable or usable in production, yet. It is highly unlikely that we pick up this issue for CodeMirror 5, though.

I know this is an older thread but a better solution (and one that worked for me) is just to change the styling of the cursor from:
.CodeMirror-cursor {
  border-left: 1px solid black;
  border-right: none;
  width: 0;
}

to
.CodeMirror-cursor {
  border-left: thin solid black;
  border-right: none;
  width: 0;
}

The real problem is the browser is trying to calculate a sub-pixel border-width for odd resolutions/zoom levels. The css border-width: thin property seems to ignore the calculation and always remain 1px.
I couldn't find much on browser compatibility but I'd be happy to look more into it and make a PR if that would be helpful for you guys.
Here is the relevant line.
https://github.com/codemirror/CodeMirror/blob/17457466015551c7bf9292896baaa69e738f0d49/lib/codemirror.css#L46

That's a useful trick, but at this point, unless there is some evidence that thin will usually end up being around a pixel in width, I'd be worried about changing the default style and breaking someone's setup.

@kay999 I am facing same problem but where to put this code ?

@kay999 your workaround breaks fat cursor mode, use this instead:
:not(.cm-fat-cursor) .CodeMirror-cursor {
    width: 1px !important;
}

In my case, I needed
:not(.cm-fat-cursor) .CodeMirror-cursor {
    width: 1px !important;
    height: 18px !important;
}

environment

Electron v8.2.0
codemirror 5.52.2
Manjaro Linux
react v16.13.1
codemirror used in react-bootstrap Tab container

question

How is cursor height calculated?

My solution was to give the cursor a margin-left to shove it into view, because it is only ever one pixel off (in my environment, at least).
.CodeMirror-cursor {
  margin-left: 1px;
}


text:
Color fix for solarized light vim mode

There is a colour issue with the solarized light theme. In vim mode, the cursor is not visible because it has the same colour as the background. This screenshot has the upper brackets selected, and you can see only the brackets get highlighted, but not the cursor.

This is the fixed one with colour taken from the previous version in code mirror.

After a small research, this was most probably introduced in #4036 . The fat cursor colour is also from that issue.

Thanks. Merged as 524d006

authors: SuNaden marijnh


text:
Add support for dynamic import operator to JavaScript mode

Adds support for dynamic import syntax to the JavaScript mode. Currently this isn't handled, so, for instance, property access from dynamic imports - like
import('foo').then(() => {});

Highlights then as a variable, not a property.
This PR allows for dynamic imports at the top level by detecting (, and handles imports in expressions by just continuing to the expression mode when they're detected.

dynamic import is stage 3, but I think that's okay for CodeMirror. Could you add a test?

👍 Test cases added.

Thanks!

authors: adrianheine marijnh tmcw


text:
Updating of SSH config

I noticed the extension adds it's own Host coder-vscode--* entry to SSH config, or more specifically. The file defined by:
	"remote.SSH.configFile": "/Users/maf/.ssh/coder"

I'm wondering it we should do one of two things:

Make sure we use a managed block, like we do with coder (# ------------{START,END}-CODER------------)
See if we can override remote.SSH.configFile when connecting

If it works, 2) would allow us to fully manage the file and not make changes in the users files, a very clean approach.
Alternatively 1) would be an improvement from current since we won't know if/when we'll need to make changes to the host configuration, and doing so automatically without a block is dangerous.

The problem with 2) is that it's similar to how editing the SSH config file is, but globally for all of VS Code. It'd be nice if VS Code allowed settings to modify settings temporarily, but that'd be a bit weird.

We now do this!

authors: kylecarbs mafredri

repo: coder/vscode-coder


text:
Remember VS Code workspace

I use a workspace in VS Code to have multiple projects open at once. Is there way to configure my extension to always open this workspace?
Right now, it is always opening the directory specified by the Coder agent.

It should always open the most recent directory or workspace now (if the module is being used then open_recent has to be set).

authors: bpmct code-asher


text:
Add sort event to columns

Adds a sort event that is emitted on columns as per #44

The sort feature it's ok =)
Nice work man @ceejtron, but, Can we add an arrows for show DESC or ASC?
Example.

authors: ceejtron coderdiaz

repo: coderdiaz/vue-datasource

license: mit


text:
default_build_paths and GNUInstallDirs

Should default_build_paths.cmake use GNUInstallDirs?
It currently stores binaries under ${CMAKE_BINARY_DIR}/bin and libraries under ${CMAKE_BINARY_DIR}/lib but on 64-bit system the latter should rather be ${CMAKE_BINARY_DIR}/lib64.

The fix would be:
include(GNUInstallDirs)

set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_BINDIR})

Yes, you are right. Your suggestion is better than the current solution.

authors: bast robertodr

repo: coderefinery/autocmake


text:
Button title length issue

I noticed that if you set the button titles too long, it causes the button width to extend and look ugly.

Fixed this in the pull request as well

repo: codestergit/SweetAlert-iOS


text:
Failure at sentry:validate_config

gem version
v0.4.1
error message
  INFO [sentry:validate_config] Validating Sentry notification config
(Backtrace restricted to imported tasks)
cap aborted!
NoMethodError: undefined method `blank?' for #<String:0x00005577f98d6c58>

Tasks: TOP => deploy:starting => sentry:validate_config
(See full trace by running task with --trace)
The deploy has failed with an error: undefined method `blank?' for #<String:0x00005577f98d6c58>

code location
https://github.com/codeur/capistrano-sentry/blob/b9a12b221ad18dba36077f7ce6566067a44b0e2d/lib/capistrano/tasks/sentry.rake#L23
causing
blank? is the method of Ruby on Rails.
https://api.rubyonrails.org/v6.0.3.1/classes/String.html#method-i-blank-3F
It is not in method of ruby's string class.
irb(main):003:0> 'string'.respond_to?(:blank?)
=> false

comment
I'm at work so I created an issue first.
When I find the time, I will create a pull request.
Thanks for your gem.

Thank you for your help. I "rubocoped" the cop too quickly. I'll fix that now.

A new gem has been released (v0.4.2)

authors: burisu iwaseasahi

repo: codeur/capistrano-sentry


text:
add recursive code for c

Signed-off-by: Ritesh Dabral riteshdabral1@gmail.com
Why:

#481

#482

Closes #ISSUE_NUMBER
Closes #482
What's being changed:
Add logic to find the sq of sum using recursive approach for 'C'

@PrajwalBorkar @victoriacheng15
Please review

@victoriacheng15 @PrajwalBorkar
Please verify and merge this PR

@Ritesh-Dabral Please dont ping us for review. We will review when we are able to do so. Thank you!

repo: codinasion/program


text:
Current State and Direction of LiteJsonDb (Node.js)

👋 Hi team,
I’m taking over the development of the Node.js version of LiteJsonDb, and I wanted to address some concerns about where we’re heading.
To be honest, things aren’t in great shape right now. The original codebase was more structured, which made it easier to maintain and build upon. Unfortunately, some of the recent changes have made the project harder to manage.
For example, Bakar’s pull request introduces some great features (props for that), but it lacks clear architecture and modularity. This has kept the changes from being included in a release so far, despite the effort involved.
On the other hand, Doni rewrote the entire codebase in TypeScript in another pull request. While TypeScript has its benefits, this decision seems to have been made without much discussion, and it’s a significant shift from the Node.js native approach most of us have been following. We need consistency in our tools and workflow to stay efficient as a team.
Lastly—and let’s be real—the Python version of LiteJsonDb is far ahead of the Node.js version. This gap is something we need to address, as it’s holding us back.
Here’s what I propose:

Stick to Node.js native for now to maintain team alignment and consistency.
Migrate features from the Python version to the Node.js version step by step, so we can catch up.
Redesign the architecture to make it more modular, maintainable, and scalable.

This isn’t about pointing fingers—Bakar and Doni, your contributions are appreciated. But we need to take a step back, refocus, and tackle the bigger picture to move the project forward.
What do you all think? I’m here to discuss and figure out the best way forward together.
Let’s fix this together!

Hi Codingtuto and Team,
Thank you for taking the time to address these concerns and for outlining a path forward. I completely understand the need for consistency and alignment within the team, and I genuinely appreciate the feedback regarding the TypeScript rewrite.
When I decided to rewrite the codebase in TypeScript, my intention was to leverage the additional type safety and tooling support it provides, which I believed could enhance the long-term maintainability of the project. However, I acknowledge that this was a significant shift, and I should have initiated more discussion with the team before making such a major decision. I apologize if this caused any disruption or misalignment.
Regarding the proposal, I agree that:

Team alignment and consistency are essential for the success of the project. If sticking to Node.js native is the agreed path forward, I’m happy to work on aligning my contributions to this standard.
Adopting features from the Python version step by step is a practical approach. I’d be glad to assist in identifying and migrating these features to the Node.js version.
A modular architecture would benefit the project immensely, and I’m excited to contribute to this effort.
I’d also love to hear the team’s thoughts on how we can integrate some of the benefits of TypeScript into the project in the future, perhaps in a more phased and consensual manner. If there’s an opportunity to revisit this discussion later, I’d be happy to contribute my perspective.

Lastly, I want to reaffirm my commitment to the project and the team. I value everyone’s efforts, including Bakar’s feature additions, and I’m looking forward to collaborating closely to improve LiteJsonDb together.
Let me know how I can help with the next steps.
Best regards,
Doni

👋 Hey @DoniLite
First off—no need to apologize. Really. You took the initiative, rewrote the entire codebase, and submitted a pull request. That’s real work! Compare that to the usual “I’ll totally contribute soon” crowd—you know who you are 👀—and you’re already ahead. So, hats off to you for showing both skill and commitment.
Now, onto TypeScript. I get it—type safety, better tooling, fewer late-night debugging disasters. It’s a solid choice, and I can see where you were coming from. But here’s the deal: we’ve got five other contributors actively coding right now, and they’re all in Node.js native. That’s our team’s happy place at the moment, and consistency is key. So for now, let’s stick to what works for the majority, and revisit TypeScript later, maybe when the dust settles.
I really appreciate your willingness to align with the team direction, especially regarding the Python features migration. Between your skills, Bakar’s features (which we’ll modularize soon, promise!), and a bit more coordination, we’ve got everything we need to take LiteJsonDb to the next level. 🚀
Also, to everyone lurking: Doni’s out here putting in the work—what’s your excuse? 😉
Let’s make this happen. Looking forward to the next steps!

Thanks for the kind words and clear direction!
I completely understand the need for consistency, and I’m all in for sticking to Node.js native for now. I’ll start reviewing the Python features we could prioritize for migration, and I’m here to help with modularizing Bakar’s features as well.
Let’s keep the momentum going—excited to see how far we can take LiteJsonDb together! 🚀

Here we go, now the contributions are open we have successfully merged the different contributions : https://t.me/codingtuto/120552

ANY OTHER CHANGES / SUGGESTION to make  it better?
@Bakarseck @DoniLite @codingtuto

authors: DoniLite anonymmouscoder codingtuto

repo: codingtuto/LiteJsonDB-Node


text:
Can't uninstall tabnine

Hello, I'm not super familiar with github and so I hope I'm putting this in the right place.
I followed the instructions for installing tabnine in jupyter lab and it worked great. Now I'd like to uninstall it, but when entering the following commands into my terminal:
jupyter nbextension uninstall --py jupyter_tabnine
pip3 uninstall jupyter-tabnine
I get the following output:
Traceback (most recent call last):   File "/Users/glados/opt/anaconda3/bin/jupyter-nbextension", line 11, in <module>     sys.exit(main())   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/jupyter_core/application.py", line 264, in launch_instance     return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/traitlets/config/application.py", line 664, in launch_instance     app.start()   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/notebook/nbextensions.py", line 980, in start     super().start()   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/jupyter_core/application.py", line 253, in start     self.subapp.start()   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/notebook/nbextensions.py", line 888, in start     self.toggle_nbextension_python(self.extra_args[0])   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/notebook/nbextensions.py", line 864, in toggle_nbextension_python     logger=self.log)   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/notebook/nbextensions.py", line 498, in disable_nbextension_python     logger=logger)   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/notebook/nbextensions.py", line 372, in _set_nbextension_state_python     m, nbexts = _get_nbextension_metadata(module)   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/notebook/nbextensions.py", line 1114, in _get_nbextension_metadata     m = import_item(module)   File "/Users/glados/opt/anaconda3/lib/python3.7/site-packages/traitlets/utils/importstring.py", line 42, in import_item     return __import__(parts[0])
ModuleNotFoundError: No module named 'jupyter_tabnine'
I'm assuming that last line "ModuleNotFoundError: No module named 'jupyter_tabnine' " is the core issue.
For reference I use jupyterlab which I always launch from the anaconda gui
When I open jupyterlab, tabnine is still there and still working so clearly the module is somewhere
Any suggestions for how to successfully uninstall tabnine?
gz#12369

Hi @I-Avery you say you use Jupyer Lab, right?
Will you try run pip3 uninstall jupyterlab-tabnine ?

Great suggestion! That worked worked perfectly thanks. I'll close the issue.

authors: I-Avery maya-tabnine

repo: codota/jupyter-tabnine


text:
fix redundancy in chatManager class

The getMessageChainTo()  method in the MessageTree class currently returns an array that already includes the message itself, so no need to push it again into the messages array.

The code is a bit confusing here and should probably be rewritten to make it more clear, but because getMessageChainTo() is passed message.parentID (as opposed to message.id) it returns the list of messages ending with the previous message - the one being replied to - and not the new message.
The MessageTree class stores messages in a tree structure, where each message keeps track of its parent (the message it was a reply to) and replies (may have multiple replies if the user edited or regenerated a message). getMessageChainTo() scans up through the tree to find the series of messages leading to the new message, not including the new message, and not including any messages on other 'branches' of the tree (like older edits). Hope that makes sense.

authors: cogentapps fjiasigmoid

repo: cogentapps/chat-with-gpt


text:
add more colormap and switch to numpy binaries

closes #91
after https://github.com/cogeotiff/rio-tiler/pull/92, this PR refactor how we store color map (.txt to numpy binary .npy)
https://github.com/cogeotiff/rio-tiler/blob/5ea11e008b840d8b2a41f7f96f0540d73bc26dca/rio_tiler/cmap/__init__.py#L2-L19
@DanSchoppe could you please make sure the rplumbo colormap still work for you ?
@dionhaefner thanks for your help on this one 🙏

Thanks for this! Investigating now...

@DanSchoppe I'm going to merge this today except if you find something ;-)

Hey @vincentsarago, sorry I didn't get positive confirmation on this before you needed to merge.
I took a quick crack at testing this yesterday but was getting errors when calling utils.array_to_image() with a colormap. Turns out I had forgotten about the format="gdal" param in the call to utils.get_colormap() 🙄
Anyway, I was able to get this working and it looks good! No diff on the tile returned from a tile retrieved before/after this patch.

authors: DanSchoppe vincentsarago

repo: cogeotiff/rio-tiler


text:
depot doc does not work in newly generated library project in workspace

I basically did
cargo install depot-js --locked
depot setup
depot new --workspace depot-workspace
cd depot-workspace
depot new --target site --platform browser depot-test
depot new --target lib --platform browser depot-test-lib

to generate a project structure to test depot for the first time today.
I then tried the various commands and (from what I can tell at a casual glance) they all seem to be working as expected but
depot doc

prints
ws/typedoc
│ [warning] The 'typedoc' key in ./packages/depot-test-lib/package.json was used by the legacy-packages entryPointStrategy and will be ignored.
│ [info] Converting project at ./packages/depot-test-lib
│ [warning] No entry points were provided, this is likely a misconfiguration.
│ [info] Merging converted projects
│ [info] Documentation generated at ./docs
└─ finished

and the resulting documentation does not seem to include the add function that is generated as an example or really much of anything other than the package name as a module.

Ah, it seems that Typedoc changed their configuration strategy to use tsconfig.json instead of package.json. I'll update Depot to match, thanks.

authors: taladar willcrichton

repo: cognitive-engineering-lab/depot


text:
my env has wrong pandas version

This is probably user-error of some form, but since our other users will encounter it too I figured I'd file an issue.
I'm using this environment file:
name: integration-tests
channels:
  - coiled
  - conda-forge
dependencies:
  - coiled-runtime=0.0.3
  - pip
  - pip:
      - junitparser~=2.0.0
      - slack_sdk
      - coiled>=0.0.47
      - ddtrace
      - pytest-repeat~=0.9.1
      - pytest-json-report~=1.4.1

mamba env create -f integration-tests/environment.yml -n integration_tests13 gets me pandas 1.4.2, when I expected 1.3.5 (given the coiled-runtime pin).
There's not even a warning about something weird happening.
Conda behaves the same way, but at some point I stopped being able to repro the issue there.
mamba env create -f integration-tests/environment.yml -n integration_tests13
conda-forge/osx-64       Using cache
conda-forge/noarch       Using cache
pkgs/main/noarch         [====================] (00m:00s) No change
pkgs/r/osx-64            [====================] (00m:00s) No change
pkgs/main/osx-64         [====================] (00m:00s) No change
pkgs/r/noarch            [====================] (00m:00s) No change
coiled/osx-64            [====================] (00m:00s) No change
coiled/noarch            [====================] (00m:00s) No change

Looking for: ['altair', 'altair_saver', 'beautifulsoup4~=4.9.3', 'boto3', "s3fs[version='>=2021.8.0']", 'flaky~=3.7.0', 'git', 'nodejs~=14.15.1', "pandas[version='>=1.4.0']", 'pip', 'pre-commit', 'pytest-asyncio~=0.18.0', 'pytest-selenium~=2.0.1', 'pytest-timeout~=2.1.0', 'pytest-xdist~=2.5.0', 'pytest~=7.0.1', 'python-dotenv~=0.15.0', 'python=3.8', 'requests~=2.24.0', 'semver~=2.13.0', 'structlog~=20.2.0', 'yarn~=1.22.10', 'click', 'python-blosc=1.10.2', 'lz4=3.1.10', 'numpy=1.21.1', "cloudpickle[version='>=1.5.0']", "msgpack-python[version='>=0.6.0']", 'filelock']

Transaction

  Prefix: /Users/davidchudzicki/miniconda3/envs/integration_tests13

  Updating specs:

   - altair
   - altair_saver
   - beautifulsoup4 ~=4.9.3
   - boto3
   - s3fs[version='>=2021.8.0']
   - flaky ~=3.7.0
   - git
   - nodejs ~=14.15.1
   - pandas[version='>=1.4.0']
   - pip
   - pre-commit
   - pytest-asyncio ~=0.18.0
   - pytest-selenium ~=2.0.1
   - pytest-timeout ~=2.1.0
   - pytest-xdist ~=2.5.0
   - pytest ~=7.0.1
   - python-dotenv ~=0.15.0
   - python=3.8
   - requests ~=2.24.0
   - semver ~=2.13.0
   - structlog ~=20.2.0
   - yarn ~=1.22.10
   - click
   - python-blosc=1.10.2
   - lz4=3.1.10
   - numpy=1.21.1
   - cloudpickle[version='>=1.5.0']
   - msgpack-python[version='>=0.6.0']
   - filelock

  Package                           Version  Build               Channel                  Size
────────────────────────────────────────────────────────────────────────────────────────────────
  Install:
────────────────────────────────────────────────────────────────────────────────────────────────

  + aiobotocore                       2.2.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + aiohttp                           3.8.1  py38hed1de0f_1      conda-forge/osx-64     Cached
  + aioitertools                     0.10.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + aiosignal                         1.2.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + altair                            4.2.0  pyhd8ed1ab_1        conda-forge/noarch     Cached
  + altair_data_server                0.4.1  py_0                conda-forge/noarch     Cached
  + altair_saver                      0.5.0  py_0                conda-forge/noarch     Cached
  + altair_viewer                     0.4.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + async-timeout                     4.0.2  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + async_generator                    1.10  py_0                conda-forge/noarch     Cached
  + attrs                            21.4.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + beautifulsoup4                    4.9.3  pyhb0f4dca_0        conda-forge/noarch     Cached
  + blosc                            1.21.0  he49afe7_0          conda-forge/osx-64     Cached
  + boto3                           1.21.21  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + botocore                        1.24.21  pyhd8ed1ab_1        conda-forge/noarch     Cached
  + brotlipy                          0.7.0  py38hed1de0f_1004   conda-forge/osx-64     Cached
  + bzip2                             1.0.8  h0d85af4_4          conda-forge/osx-64     Cached
  + c-ares                           1.18.1  h0d85af4_0          conda-forge/osx-64     Cached
  + ca-certificates               2021.10.8  h033912b_0          conda-forge/osx-64     Cached
  + cairo                            1.16.0  he43a7df_1008       conda-forge/osx-64     Cached
  + certifi                       2021.10.8  py38h50d1736_2      conda-forge/osx-64     Cached
  + cffi                             1.15.0  py38h1a44b6c_0      conda-forge/osx-64     Cached
  + cfgv                              3.3.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + chardet                           3.0.4  py38h5347e94_1008   conda-forge/osx-64     Cached
  + charset-normalizer               2.0.12  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + click                             8.1.2  py38h50d1736_0      conda-forge/osx-64     Cached
  + cloudpickle                       2.0.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + cryptography                     36.0.2  py38h826b3c8_1      conda-forge/osx-64     Cached
  + curl                             7.82.0  h9f20792_0          conda-forge/osx-64     Cached
  + distlib                           0.3.4  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + entrypoints                         0.4  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + execnet                           1.9.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + expat                             2.4.8  h96cf925_0          conda-forge/osx-64     Cached
  + filelock                          3.6.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + flaky                             3.7.0  pyh9f0ad1d_0        conda-forge/noarch     Cached
  + font-ttf-dejavu-sans-mono          2.37  hab24e00_0          conda-forge/noarch     Cached
  + font-ttf-inconsolata              3.000  h77eed37_0          conda-forge/noarch     Cached
  + font-ttf-source-code-pro          2.038  h77eed37_0          conda-forge/noarch     Cached
  + font-ttf-ubuntu                    0.83  hab24e00_0          conda-forge/noarch     Cached
  + fontconfig                      2.13.94  h10f422b_0          conda-forge/osx-64     Cached
  + fonts-conda-ecosystem                 1  0                   conda-forge/noarch     Cached
  + fonts-conda-forge                     1  0                   conda-forge/noarch     Cached
  + freetype                         2.10.4  h4cff582_1          conda-forge/osx-64     Cached
  + fribidi                          1.0.10  hbcb3906_0          conda-forge/osx-64     Cached
  + frozenlist                        1.3.0  py38hed1de0f_1      conda-forge/osx-64     Cached
  + fsspec                         2022.3.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + gettext                        0.19.8.1  hd1a6beb_1008       conda-forge/osx-64     Cached
  + giflib                            5.2.1  hbcb3906_2          conda-forge/osx-64     Cached
  + git                              2.35.3  pl5321h33a4a8a_0    conda-forge/osx-64     Cached
  + graphite2                        1.3.13  h2e338ed_1001       conda-forge/osx-64     Cached
  + h11                              0.13.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + harfbuzz                          3.1.1  h159f659_0          conda-forge/osx-64     Cached
  + icu                                68.2  he49afe7_0          conda-forge/osx-64     Cached
  + identify                         2.4.12  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + idna                               2.10  pyh9f0ad1d_0        conda-forge/noarch     Cached
  + importlib-metadata               4.11.3  py38h50d1736_1      conda-forge/osx-64     Cached
  + importlib_resources               5.7.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + iniconfig                         1.1.1  pyh9f0ad1d_0        conda-forge/noarch     Cached
  + jinja2                            3.1.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + jmespath                          1.0.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + jpeg                                 9e  h0d85af4_0          conda-forge/osx-64     Cached
  + jsonschema                        4.4.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + krb5                             1.19.3  hb49756b_0          conda-forge/osx-64     Cached
  + libblas                           3.9.0  14_osx64_openblas   conda-forge/osx-64     Cached
  + libcblas                          3.9.0  14_osx64_openblas   conda-forge/osx-64     Cached
  + libcurl                          7.82.0  h9f20792_0          conda-forge/osx-64     Cached
  + libcxx                           13.0.1  hc203e6f_0          conda-forge/osx-64     Cached
  + libedit                    3.1.20191231  h0678c8f_2          conda-forge/osx-64     Cached
  + libev                              4.33  haf1e3a3_1          conda-forge/osx-64     Cached
  + libffi                            3.4.2  h0d85af4_5          conda-forge/osx-64     Cached
  + libgfortran                       5.0.0  9_3_0_h6c81a4c_23   conda-forge/osx-64     Cached
  + libgfortran5                      9.3.0  h6c81a4c_23         conda-forge/osx-64     Cached
  + libglib                          2.70.2  hf1fb8c0_4          conda-forge/osx-64     Cached
  + libiconv                           1.16  haf1e3a3_0          conda-forge/osx-64     Cached
  + liblapack                         3.9.0  14_osx64_openblas   conda-forge/osx-64     Cached
  + libnghttp2                       1.47.0  h942079c_0          conda-forge/osx-64     Cached
  + libopenblas                      0.3.20  openmp_hb3cd9ec_0   conda-forge/osx-64     Cached
  + libpng                           1.6.37  h7cec526_2          conda-forge/osx-64     Cached
  + libssh2                          1.10.0  h52ee1ee_2          conda-forge/osx-64     Cached
  + libuv                            1.41.1  h0d85af4_0          conda-forge/osx-64     Cached
  + libxml2                          2.9.12  h93ec3fd_0          conda-forge/osx-64     Cached
  + libzlib                          1.2.11  h6c3fc93_1014       conda-forge/osx-64     Cached
  + llvm-openmp                      13.0.1  hcb1a161_1          conda-forge/osx-64     Cached
  + lz4                              3.1.10  py38h5bcf07e_0      conda-forge/osx-64     Cached
  + lz4-c                             1.9.3  he49afe7_1          conda-forge/osx-64     Cached
  + markupsafe                        2.1.1  py38hed1de0f_1      conda-forge/osx-64     Cached
  + msgpack-python                    1.0.3  py38h8b7791e_1      conda-forge/osx-64     Cached
  + multidict                         6.0.2  py38hed1de0f_1      conda-forge/osx-64     Cached
  + ncurses                             6.3  h96cf925_1          conda-forge/osx-64     Cached
  + nodeenv                           1.6.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + nodejs                          14.15.4  hb529b34_1          conda-forge/osx-64     Cached
  + numpy                            1.21.1  py38had91d27_0      conda-forge/osx-64     Cached
  + openssl                          1.1.1n  h6c3fc93_0          conda-forge/osx-64     Cached
  + outcome                           1.1.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + packaging                          21.3  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pandas                            1.4.2  py38hb872667_1      conda-forge/osx-64     Cached
  + pango                           1.48.10  h056538c_2          conda-forge/osx-64     Cached
  + pcre                               8.45  he49afe7_0          conda-forge/osx-64     Cached
  + pcre2                             10.37  ha16e1b2_0          conda-forge/osx-64     Cached
  + perl                             5.32.1  2_h0d85af4_perl5    conda-forge/osx-64     Cached
  + pip                              22.0.4  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pixman                           0.40.0  hbcb3906_0          conda-forge/osx-64     Cached
  + platformdirs                      2.5.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pluggy                            1.0.0  py38h50d1736_3      conda-forge/osx-64     Cached
  + portpicker                        1.5.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pre-commit                       2.18.1  py38h50d1736_1      conda-forge/osx-64     Cached
  + psutil                            5.9.0  py38hed1de0f_1      conda-forge/osx-64     Cached
  + py                               1.11.0  pyh6c4a22f_0        conda-forge/noarch     Cached
  + pycparser                          2.21  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pyopenssl                        22.0.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pyparsing                         3.0.8  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pyrsistent                       0.18.1  py38hed1de0f_1      conda-forge/osx-64     Cached
  + pysocks                           1.7.1  py38h50d1736_5      conda-forge/osx-64     Cached
  + pytest                            7.0.1  py38h50d1736_0      conda-forge/osx-64     Cached
  + pytest-asyncio                   0.18.3  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pytest-base-url                   1.4.1  py_1                conda-forge/noarch     Cached
  + pytest-forked                     1.4.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pytest-html                       3.1.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pytest-metadata                   2.0.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pytest-selenium                   2.0.1  py_0                conda-forge/noarch     Cached
  + pytest-timeout                    2.1.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pytest-variables                  1.7.1  py_1                conda-forge/noarch     Cached
  + pytest-xdist                      2.5.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + python                           3.8.13  h394c593_0_cpython  conda-forge/osx-64     Cached
  + python-blosc                     1.10.2  py38ha53d530_2      conda-forge/osx-64     Cached
  + python-dateutil                   2.8.2  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + python-dotenv                    0.15.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + python_abi                          3.8  2_cp38              conda-forge/osx-64     Cached
  + pytz                             2022.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + pyyaml                              6.0  py38hed1de0f_4      conda-forge/osx-64     Cached
  + readline                            8.1  h05e3726_0          conda-forge/osx-64     Cached
  + requests                         2.24.0  pyh9f0ad1d_0        conda-forge/noarch     Cached
  + s3fs                           2022.3.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + s3transfer                        0.5.2  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + selenium                          4.1.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + semver                           2.13.0  pyh9f0ad1d_0        conda-forge/noarch     Cached
  + setuptools                       62.1.0  py38h50d1736_0      conda-forge/osx-64     Cached
  + six                              1.16.0  pyh6c4a22f_0        conda-forge/noarch     Cached
  + sniffio                           1.2.0  py38h50d1736_3      conda-forge/osx-64     Cached
  + sortedcontainers                  2.4.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + soupsieve                         2.3.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + sqlite                           3.38.2  hb516253_0          conda-forge/osx-64     Cached
  + structlog                        20.2.0  pyhd3deb0d_0        conda-forge/noarch     Cached
  + tenacity                          6.3.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + tk                               8.6.12  h5dbffcc_0          conda-forge/osx-64     Cached
  + toml                             0.10.2  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + tomli                             2.0.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + toolz                            0.11.2  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + tornado                             6.1  py38hed1de0f_3      conda-forge/osx-64     Cached
  + trio                             0.20.0  py38h50d1736_1      conda-forge/osx-64     Cached
  + trio-websocket                    0.9.2  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + typing-extensions                 4.2.0  hd8ed1ab_0          conda-forge/noarch     Cached
  + typing_extensions                 4.2.0  pyha770c72_0        conda-forge/noarch     Cached
  + ukkonen                           1.0.1  py38h8b7791e_2      conda-forge/osx-64     Cached
  + urllib3                         1.25.11  py_0                conda-forge/noarch     Cached
  + vega-cli                         5.17.0  ha93a217_3          conda-forge/osx-64     Cached
  + vega-lite-cli                    4.17.0  hf542fc5_1          conda-forge/osx-64     Cached
  + virtualenv                      20.14.1  py38h50d1736_0      conda-forge/osx-64     Cached
  + wheel                            0.37.1  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + wrapt                            1.14.0  py38hed1de0f_1      conda-forge/osx-64     Cached
  + wsproto                           1.1.0  py38h50d1736_0      conda-forge/osx-64     Cached
  + xz                                5.2.5  haf1e3a3_1          conda-forge/osx-64     Cached
  + yaml                              0.2.5  h0d85af4_2          conda-forge/osx-64     Cached
  + yarl                              1.7.2  py38hed1de0f_2      conda-forge/osx-64     Cached
  + yarn                            1.22.18  h694c41f_0          conda-forge/osx-64     Cached
  + zipp                              3.8.0  pyhd8ed1ab_0        conda-forge/noarch     Cached
  + zlib                             1.2.11  h6c3fc93_1014       conda-forge/osx-64     Cached

  Summary:

  Install: 167 packages

  Total download: 0  B

────────────────────────────────────────────────────────────────────────────────────────────────

Preparing transaction: done
Verifying transaction: done
Executing transaction: done
Installing pip dependencies: | Ran pip subprocess with arguments:
['/Users/davidchudzicki/miniconda3/envs/integration_tests13/bin/python', '-m', 'pip', 'install', '-U', '-r', '/Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt']
Pip subprocess output:
Collecting junitparser~=2.0.0
  Using cached junitparser-2.0.0-py2.py3-none-any.whl (10 kB)
Collecting slack_sdk
  Using cached slack_sdk-3.15.2-py2.py3-none-any.whl (261 kB)
Collecting coiled>=0.0.47
  Using cached coiled-0.0.74-py3-none-any.whl (139 kB)
Collecting ddtrace
  Using cached ddtrace-1.0.1-cp38-cp38-macosx_10_9_x86_64.whl (1.4 MB)
Collecting pytest-repeat~=0.9.1
  Using cached pytest_repeat-0.9.1-py2.py3-none-any.whl (4.3 kB)
Collecting pytest-json-report~=1.4.1
  Using cached pytest_json_report-1.4.1-py3-none-any.whl (12 kB)
Collecting future
  Using cached future-0.18.2-py3-none-any.whl
Collecting backoff>=1.10.0
  Using cached backoff-1.11.1-py2.py3-none-any.whl (13 kB)
Requirement already satisfied: aiobotocore>=1.1.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2.2.0)
Requirement already satisfied: pandas>=1.1.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.4.2)
Requirement already satisfied: jmespath in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.0.0)
Collecting ipython
  Using cached ipython-8.2.0-py3-none-any.whl (750 kB)
Collecting click<=8.0,>=7.1
  Using cached click-8.0.0-py3-none-any.whl (96 kB)
Requirement already satisfied: aiohttp in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (3.8.1)
Collecting distributed>=2.23.0
  Using cached distributed-2022.4.1-py3-none-any.whl (855 kB)
Requirement already satisfied: typing-extensions in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (4.2.0)
Requirement already satisfied: boto3 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.21.21)
Requirement already satisfied: jinja2 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (3.1.1)
Requirement already satisfied: s3fs in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2022.3.0)
Collecting dask[complete]>=2.23.0
  Using cached dask-2022.4.1-py3-none-any.whl (1.1 MB)
Collecting rich>=11.2.0
  Using cached rich-12.2.0-py3-none-any.whl (229 kB)
Requirement already satisfied: six>=1.12.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from ddtrace->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 4)) (1.16.0)
Requirement already satisfied: packaging>=17.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from ddtrace->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 4)) (21.3)
Requirement already satisfied: attrs>=19.2.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from ddtrace->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 4)) (21.4.0)
Collecting protobuf>=3
  Using cached protobuf-3.20.0-cp38-cp38-macosx_10_9_x86_64.whl (962 kB)
Requirement already satisfied: tenacity>=5 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from ddtrace->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 4)) (6.3.1)
Requirement already satisfied: pytest>=3.6 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pytest-repeat~=0.9.1->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 5)) (7.0.1)
Requirement already satisfied: pytest-metadata in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pytest-json-report~=1.4.1->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 6)) (2.0.1)
Requirement already satisfied: wrapt>=1.10.10 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiobotocore>=1.1.1->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.14.0)
Requirement already satisfied: botocore<1.24.22,>=1.24.21 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiobotocore>=1.1.1->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.24.21)
Requirement already satisfied: aioitertools>=0.5.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiobotocore>=1.1.1->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (0.10.0)
Requirement already satisfied: frozenlist>=1.1.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiohttp->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.3.0)
Requirement already satisfied: yarl<2.0,>=1.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiohttp->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.7.2)
Requirement already satisfied: charset-normalizer<3.0,>=2.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiohttp->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2.0.12)
Requirement already satisfied: multidict<7.0,>=4.5 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiohttp->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (6.0.2)
Requirement already satisfied: aiosignal>=1.1.2 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiohttp->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.2.0)
Requirement already satisfied: async-timeout<5.0,>=4.0.0a3 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from aiohttp->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (4.0.2)
Requirement already satisfied: cloudpickle>=1.1.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from dask[complete]>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2.0.0)
Requirement already satisfied: toolz>=0.8.2 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from dask[complete]>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (0.11.2)
Requirement already satisfied: fsspec>=0.6.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from dask[complete]>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2022.3.0)
Collecting partd>=0.3.10
  Using cached partd-1.2.0-py3-none-any.whl (19 kB)
Requirement already satisfied: pyyaml>=5.3.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from dask[complete]>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (6.0)
Collecting bokeh>=2.4.2
  Using cached bokeh-2.4.2-py3-none-any.whl (18.5 MB)
Requirement already satisfied: numpy>=1.18 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from dask[complete]>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.21.1)
Requirement already satisfied: msgpack>=0.6.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from distributed>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.0.3)
Requirement already satisfied: psutil>=5.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from distributed>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (5.9.0)
Requirement already satisfied: sortedcontainers!=2.0.0,!=2.0.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from distributed>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2.4.0)
Collecting zict>=0.1.3
  Using cached zict-2.1.0-py3-none-any.whl (11 kB)
Requirement already satisfied: tornado>=6.0.3 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from distributed>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (6.1)
Collecting tblib>=1.6.0
  Using cached tblib-1.7.0-py2.py3-none-any.whl (12 kB)
Requirement already satisfied: urllib3 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from distributed>=2.23.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (1.25.11)
Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from packaging>=17.1->ddtrace->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 4)) (3.0.8)
Requirement already satisfied: python-dateutil>=2.8.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pandas>=1.1.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2.8.2)
Requirement already satisfied: pytz>=2020.1 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pandas>=1.1.0->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2022.1)
Requirement already satisfied: iniconfig in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pytest>=3.6->pytest-repeat~=0.9.1->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 5)) (1.1.1)
Requirement already satisfied: pluggy<2.0,>=0.12 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pytest>=3.6->pytest-repeat~=0.9.1->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 5)) (1.0.0)
Requirement already satisfied: py>=1.8.2 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pytest>=3.6->pytest-repeat~=0.9.1->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 5)) (1.11.0)
Requirement already satisfied: tomli>=1.0.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from pytest>=3.6->pytest-repeat~=0.9.1->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 5)) (2.0.1)
Collecting pygments<3.0.0,>=2.6.0
  Using cached Pygments-2.11.2-py3-none-any.whl (1.1 MB)
Collecting commonmark<0.10.0,>=0.9.0
  Using cached commonmark-0.9.1-py2.py3-none-any.whl (51 kB)
Requirement already satisfied: s3transfer<0.6.0,>=0.5.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from boto3->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (0.5.2)
Collecting traitlets>=5
  Using cached traitlets-5.1.1-py3-none-any.whl (102 kB)
Collecting jedi>=0.16
  Using cached jedi-0.18.1-py2.py3-none-any.whl (1.6 MB)
Collecting prompt-toolkit!=3.0.0,!=3.0.1,<3.1.0,>=2.0.0
  Using cached prompt_toolkit-3.0.29-py3-none-any.whl (381 kB)
Collecting pickleshare
  Using cached pickleshare-0.7.5-py2.py3-none-any.whl (6.9 kB)
Collecting stack-data
  Using cached stack_data-0.2.0-py3-none-any.whl (21 kB)
Collecting appnope
  Using cached appnope-0.1.3-py2.py3-none-any.whl (4.4 kB)
Requirement already satisfied: setuptools>=18.5 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from ipython->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (62.1.0)
Collecting matplotlib-inline
  Using cached matplotlib_inline-0.1.3-py3-none-any.whl (8.2 kB)
Collecting pexpect>4.3
  Using cached pexpect-4.8.0-py2.py3-none-any.whl (59 kB)
Collecting decorator
  Using cached decorator-5.1.1-py3-none-any.whl (9.1 kB)
Collecting backcall
  Using cached backcall-0.2.0-py2.py3-none-any.whl (11 kB)
Requirement already satisfied: MarkupSafe>=2.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from jinja2->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2.1.1)
Collecting pillow>=7.1.0
  Using cached Pillow-9.1.0-cp38-cp38-macosx_10_9_x86_64.whl (3.1 MB)
Collecting parso<0.9.0,>=0.8.0
  Using cached parso-0.8.3-py2.py3-none-any.whl (100 kB)
Collecting locket
  Using cached locket-0.2.1-py2.py3-none-any.whl (4.1 kB)
Collecting ptyprocess>=0.5
  Using cached ptyprocess-0.7.0-py2.py3-none-any.whl (13 kB)
Collecting wcwidth
  Using cached wcwidth-0.2.5-py2.py3-none-any.whl (30 kB)
Requirement already satisfied: idna>=2.0 in /Users/davidchudzicki/miniconda3/envs/integration_tests13/lib/python3.8/site-packages (from yarl<2.0,>=1.0->aiohttp->coiled>=0.0.47->-r /Users/davidchudzicki/integration-tests/condaenv.y095ykln.requirements.txt (line 3)) (2.10)
Collecting heapdict
  Using cached HeapDict-1.0.1-py3-none-any.whl (3.9 kB)
Collecting pure-eval
  Using cached pure_eval-0.2.2-py3-none-any.whl (11 kB)
Collecting asttokens
  Using cached asttokens-2.0.5-py2.py3-none-any.whl (20 kB)
Collecting executing
  Using cached executing-0.8.3-py2.py3-none-any.whl (16 kB)
Installing collected packages: wcwidth, pure-eval, ptyprocess, pickleshare, heapdict, executing, commonmark, backcall, appnope, zict, traitlets, tblib, slack_sdk, pygments, protobuf, prompt-toolkit, pillow, pexpect, parso, locket, future, decorator, click, backoff, asttokens, stack-data, rich, partd, matplotlib-inline, junitparser, jedi, ddtrace, bokeh, pytest-repeat, ipython, dask, pytest-json-report, distributed, coiled
  Attempting uninstall: click
    Found existing installation: click 8.1.2
    Uninstalling click-8.1.2:
      Successfully uninstalled click-8.1.2
Successfully installed appnope-0.1.3 asttokens-2.0.5 backcall-0.2.0 backoff-1.11.1 bokeh-2.4.2 click-8.0.0 coiled-0.0.74 commonmark-0.9.1 dask-2022.4.1 ddtrace-1.0.1 decorator-5.1.1 distributed-2022.4.1 executing-0.8.3 future-0.18.2 heapdict-1.0.1 ipython-8.2.0 jedi-0.18.1 junitparser-2.0.0 locket-0.2.1 matplotlib-inline-0.1.3 parso-0.8.3 partd-1.2.0 pexpect-4.8.0 pickleshare-0.7.5 pillow-9.1.0 prompt-toolkit-3.0.29 protobuf-3.20.0 ptyprocess-0.7.0 pure-eval-0.2.2 pygments-2.11.2 pytest-json-report-1.4.1 pytest-repeat-0.9.1 rich-12.2.0 slack_sdk-3.15.2 stack-data-0.2.0 tblib-1.7.0 traitlets-5.1.1 wcwidth-0.2.5 zict-2.1.0

done
#
# To activate this environment, use
#
#     $ conda activate integration_tests13
#
# To deactivate an active environment, use
#
#     $ conda deactivate

(integration_tests12)  /Users/davidchudzicki $

Thanks for reporting @dchudz. Unfortunately I'm not able to reproduce with mamba env create or conda env create. In both cases I end up with pandas=1.3.5 installed (meaning the coiled-runtime pinning is working as expected).

Conda behaves the same way, but at some point I stopped being able to repro the issue there

Just checking, are you still able to reproduce with mamba?
I see pandas[version='>=1.4.0'] appearing in the Looking for: output from mamba env create that you posted. From what I can when running mamba locally, the packages that listed in the Looking for: line are the conda (but not pip) packages in my conda environment file. So when I run mamba env create with the environment file you posted, I see
Looking for: ['coiled-runtime=0.0.3', 'pip']

So just to confirm, when you see pandas=1.4.2 getting installed locally, you're pointing to an environment file that looks like:
name: integration-tests
channels:
  - coiled
  - conda-forge
dependencies:
  - coiled-runtime=0.0.3
  - pip
  - pip:
      - junitparser~=2.0.0
      - slack_sdk
      - coiled>=0.0.47
      - ddtrace
      - pytest-repeat~=0.9.1
      - pytest-json-report~=1.4.1

Correct?

@dchudz are you sure you could replicate before with the env file you showed? I can't replicate with that, but can replicate with the version of integration-tests/environment.yml in our Coiled repo. Seems like maybe it's some of the extra conda packages we have there.

@jrbourbeau @ntabris apologies - I was trying to make the example more minimal. I thought I had it still repro'ing with that smaller env, but our full one (used by the integration tests right now is):
name: integration-tests
channels:
  - coiled
  - conda-forge
dependencies:
  - coiled-runtime=0.0.3
  - altair
  - altair_saver
  - beautifulsoup4~=4.9.3
  - boto3
  - s3fs>=2021.8.0
  - flaky~=3.7.0
  - git
  - ipython==8
  - nodejs
  - pip
  - pre-commit
  - pytest-asyncio~=0.18.0
  - pytest-selenium~=2.0.1
  - pytest-timeout~=2.1.0
  - pytest-xdist~=2.5.0
  - pytest~=7.0.1
  - python-dotenv~=0.15.0
  - python=3.8
  - requests~=2.24.0
  - semver~=2.13.0
  - structlog~=20.2.0
  - click
  - filelock
  - pip:
      - junitparser~=2.0.0
      - slack_sdk
      - coiled>=0.0.47
      - ddtrace
      - pytest-repeat~=0.9.1
      - pytest-json-report~=1.4.1

That's specified here: https://gitlab.com/coiled/cloud/-/blob/114ca0043e6501e95f74cdf220d50168adfeb79b/integration-tests/environment.yml
Even with that full one, my laptop no longer repros the problem. This seems very non-deterministic for some reason.
We still have the problem in CI: https://gitlab.com/coiled/cloud/-/jobs/2346050161

It might be click. If I remove click but leave everything else, then conda env create gives me pandas 1.3.5. If I have click then I get pandas 1.4.1.
Specifically, here's env that gives me 1.4.1:
name: integration-tests
channels:
  - coiled
  - conda-forge
dependencies:
  - coiled-runtime=0.0.3
  - pip
  - python=3.8
  - click
  - pip:
      - junitparser~=2.0.0
      - slack_sdk
      - coiled>=0.0.47
      - ddtrace
      - pytest-repeat~=0.9.1
      - pytest-json-report~=1.4.1

If I pin click to 8.0.0 in the env.yml (https://github.com/coiled/coiled-runtime/issues/66#issuecomment-1101540865) and don't change anything else, then I get pandas 1.3.5. So that might be a solution for the CI problem we're having.

@ntabris I'm surprised by that... pandas doesn't even appear in the click repo!

Yeah, we've seen click version constrains can lead to some strange behavior (xref https://github.com/coiled/coiled-runtime/pull/57). Given that click is included in coiled-runtime, can it just be removed from the integration tests environment file?

Since this issue was originally reported, there have been several changes around click pinning. My guess is this is no longer an issue, so I'm going to close this ticket. Feel free to re-open if you run into this again and we can continue

authors: dchudz jrbourbeau ntabris

repo: coiled/coiled-runtime


text:
Fix responsiveness issues

What changed? Why?
Fix responsiveness issues. To summarize:

Move DefaultNavbar into Header, removing its children prop.
Hide account balance below breakpoint md / Tablet landscape (1024px).
Remove fixed 400px width of FormBuyCoffee.
Minor changes to Navbar's css.

Notes to reviewers
Here's how before and after look like:
Before
https://github.com/coinbase/build-onchain-apps/assets/43140758/c4416a04-00f1-4d4f-b902-044e90e9c811
After
https://github.com/coinbase/build-onchain-apps/assets/43140758/98e0b66c-0e98-4279-80d2-e2b556a5c150
How has it been tested?
Locally.

@Zizzamia for sure, let's be X friends https://twitter.com/renanmav
PS: I'm basically renanmav everywhere...

repo: coinbase/build-onchain-apps


text:
Cannot tell if a partial fill is complete - documentation says differently

When using getOrder() on a filled limit order and receiving back and Order that is a partial fill, I am not able to determine if that partial fill will be one of many or if the order is done and will only ever be partially filled.  I know that a limit order on the books can either:

Be filled completely by a single taker order
Be filled completely by multiple taker orders
Be filled partially by one or multiple taker orders

The first case is trivial to distinguish, whereas the second two are not.  Following the documentation on the GDAX API:

Orders which are no longer resting on the order book, will be marked with the done status. There is a small window between an order being done and settled. An order is settled when all of the fills have settled and the remaining holds (if any) have been removed.

From this, I drew the conclusion that by using .getOrder(orderId) and checking result.status === 'done' && order.settled === true, I would know if my limit order was completely done filling (regardless of partial or complete fill). This turned out to be wrong. On multiple occasions I have called .getOrder(orderId), checked for a 'done' status and true settle, but have only received one partial fill of two, where calling .getOrder(orderId) a few seconds later resulted in the total fill.
I am guessing this is because my limit order filled with two partial fills and i called .getOrder(orderId) after the first part filled and before the second. The big problem here is that this leaves me in a position where I don't know if I received a partial fill and there are more fills on the way, or if that partial fill is the only fill that will happen and my order will never be completely filled.
Is this a bug? Is there any way to know with 100% certainty that the filling of my order has completed, whether it was a single complete fill, several partial fills resulting in a complete fill, or partial fills resulting in an order that was not completely filled?
Thanks!

Any ideas at least if this is a bug? Should a response with 'done' and 'settled' mean that all parts of the order have been filled?

Any updates on this? Just ran into another case of a partial fill where the order was settled, but we were only seeing a partial fill, contrary to the documentation.

I have the same problem of knowing whether more fills are coming or not after canceling an order. To ameliorate this issue, I use getOrder and getFills in conjunction with each other. Here's how:
First, I poll getOrder until I get status == done or the order can't be found. Then I note the filled_size field returned from getOrder. If the order can't be found, I set filled_size to 0.
Second, I request getFills for the order. I add up all the fills I received. If the total size of the fills from getFills matches getOrder (or is close enough), great, I treat the transaction as completed. If not, I repeat the two steps.
I'm not convinced this works 100% of the time, and I wish Coinbase made it clearer. But I think it is superior to relying solely on getOrder.
Would love to hear better suggestions!

@tkriplean Thanks for the response. I took a break from my project but now I'm back at it.
I see what you are saying, and I think I achieve the same thing by just noting how big the order was that I placed and checking getOrder()'s size to see if it was completely filled or not.
The problem Is mostly with knowing if another fill is coming when I realize that getOrder()'s size is not equal to my expected fill size.
For example, I see that the sizes are not equal. Should I cancel my order now and take the partial fill that I was able to get because it's never going to fully fill / won't fully fill until hours-days later? Or is it a transaction that is going to have completely filled in seconds - in which case I can wait? It is important for my program to move on quickly. If the order is filling near instantly in several fills, that's ok.. I can wait. If it's going to fill part now and that's it, I need to know.
I'm just looking for something that tells me 'a partial fill happened, but hold up a second because the rest is being filled now' or 'a partial fill happened and that's all you're going to get'.  Maybe this isn't reasonable because GDAX has no way of distinguising this, but based off of the documentation it seemed like using 'settled' / 'done' would make this acheivable.

authors: nzhammer tkriplean

repo: coinbase/gdax-node


text:
Documentation

Hi
Is there any extended documentation, with info about functions, etc ?
Also is there way to add transparency to layer ?
Regards

Sorry, there is no extended documentation available, as it is just a simple library, in the readme, the examples cover almost all the methods and you can find information from Layers Methods section (let you mouse hover the "message" icons).
If I understand you question correctly, Imagecraft preserve image transparency automatically, you don't have to add transparency manually.

authors: IProSoft coldume

repo: coldume/imagecraft


text:
Proposal: RX.addEpoch(name, start_frame, end_frame)

Here's a proposal for a new method in RecordingExtractor (and perhaps this can serve as a template for proposing modifications to spikeinterface)
Proposed actions:

getEpochNames and getEpochInfo are no longer overloaded by subclass
add method: addEpoch(epoch_name, start_frame, end_frame)
RecordingExtractor would keep track of the epochs internally
Modify MultiRecordingExtractor to use the new addEpoch method in its constructor

Rationale:
It may be useful to add epoch information to recordings that were loaded from a format that does not support epochs. This therefore provides more flexibility. Furthermore it simplies subclasses (because they do not need to keep track of epochs).
Related information:
There are 3 types of methods in the extractors:

Required to be implemented in subclass (@abstractmethod)
May optionally be implemented in the subclass
Should not be implemented in the subclass

I agree with this, I can put this in to the main class. So the main class will currently have:

addEpoch(epoch_name, start_frame, end_frame)
getEpoch(epoch_name)

I still think we need two more functions, however, to make this complete:

removeEpoch(epoch_name)
getEpochs()

The reason for removeEpoch is if you set epochs that you no longer care about later, it should be easy to remove them. The reason for getEpochs is if you set a bunch of epochs, there should be an easy way to return how many you have set and what their frame ranges are.

I agree with removeEpoch. But rather than getEpochs, I think it is better to do:
getEpochNames() -- returns a list of epoch names
getEpoch(name) -- returns the dict containing start_frame and end_frame fields

I was thinking that getEpochInformation or getEpochs could allow the user to see which epochs are overlapping or what current epoch ranges they have. If you only have getEpochNames, then you have to get the names and then get each epoch to see how they look which would be cumbersome.

Yes it may be cumbersome, but I have learned to program APIs such that there is one and only one way of doing each thing -- and then there can be convenience functions. But having multiple ways to retrieve the same information can be problematic -- and requires more complicated testing.
Also, maybe getEpochInfo is better than getEpoch for retrieving the dict of a single epoch.

Ok, I agree with what you are saying. So the functions we could have are:

addEpoch(epoch_name, start_frame, end_frame)
getEpoch(epoch_name) --> returns SubRecordingExtractor
getEpochNames() --> returns list of names

Could getEpochNames be changed to getEpochInfo which returns a dictionary of names and frames?

I think it should be
getEpochInfo(name)
which returns the dict for just that one epoch.

Sounds good. I can try implementing that then.

If I construct a SubRecordingExtractor manually and get it an epoch name, should the RecoringExtractor store that epoch name/info?
Also, should we let epochs specify which channels it is tracking?

For second question, i think epochs are related to time, so I would say no.
In general, I don't think subrecordings need to be aware of where they came from, because that info can be kept track of by the program that is using the API.
For example:
X=Y.getEpoch('some_name')
Then if later I wanted to know the start and end frames:
Y.getEpochInfo('some_name')['start_frame']
See, it doesn't need to be stored with X.

So would have:

addEpoch(epoch_name, start_frame, end_frame)
getEpoch(epoch_name) --> returns SubRecordingExtractor
getEpochInfo() --> returns dictionary of all epochs which has 'epoch_name': (start_frame, end_frame)

Yes, but I think there should be only one epoch which has a given name. So I'm confused by the phrase "all epochs".

Currently, I am storing one dictionary that has all epoch_names as keys and each item is a key and tuple of start and end frames. I can return that whole dictionary so the user can get the names and start and end frames for their epochs.

Could you also explain this code:
if epoch_name is not None:
            e_info=parent_extractor.getEpochInfo(epoch_name)
            e_start=e_info['start_frame']
            e_end=e_info['end_frame']
            if start_frame is None:
                start_frame=e_start
            else:
                start_frame=e_start+start_frame
            if end_frame is None:
                end_frame=e_end
            else:
                end_frame=e_start+end_frame

This is in the constructor of the SubRecordingExtractor right?
If the user has specified an epoch name, then we get the info in the parent extractor for that epoch name... and use that start time and end time. But if the user also specified a start_frame and/or end_frame (in addition to epoch_name), then we assume they are requesting a start_frame and end_frame relative to the epoch.

Currently, I am storing one dictionary that has all epoch_names as keys and each item is a key and tuple of start and end frames. I can return that whole dictionary so the user can get the names and start and end frames for their epochs.

I don't think it is a good idea to return that dictionary. That's the internal way you store it, but should not be exposed in the API.

oh i see... I misunderstood the above.... it should be
getEpochInfo(epoch_name)
which returns the epoch info just for that epoch.

And it should return a dict:
{
'start_frame':[the-start-frame],
'end_frame':[the-end-frame]
}

I was thinking it could return a copy of the internal dictionary since that is the easiest way to return all names and frame information.  I would rather return all the info otherwise we would need a getEpochNames so that they could figure out which epochs they have set.
Also, I was wondering if we should remove all references to epochs in the SubRecordingExtractor. I don't think that a user should initialize a SubRecordingExtractor and have information from the parent extractor added. I think that the only way to get epochs should be through the getEpoch functionality.

Currently, the SubRecordingExtractor never uses the epoch_name and I think initializing with an epoch_name that only checks for the epoch name in the parent extractor is confusing since I may just want to name my SubRecordingExtractor and when I set epoch_name it doesn't do anything and I can't return the name

I agree with your second point.
Regarding the first, it is important not to expose the internal structure of how all epochs are stored. There are various reasons for that and it is better to have a getEpochNames() function. I can give more details if you want. It comes from clean api design principles.

Current implemenation:
def __init__(self):
        self._epochs = {}
def addEpoch(self, epoch_name, start_frame, end_frame):
        '''This function adds an epoch to your recording extractor that tracks
        a certain time period in your recording. It is stored in an internal
        dictionary of start and end frame tuples.

        Parameters
        ----------
        epoch_name: str
            The name of the epoch to be added
        start_frame: int
            The start frame of the epoch to be added (inclusive)
        end_frame: int
            The end frame of the epoch to be added (exclusive)

        '''
        #Default implementation only allows for frame info. Can override to put more info
        self._epochs[epoch_name] = {'start_frame': int(start_frame), 'end_frame': int(end_frame)}

    def removeEpoch(self, epoch_name):
        '''This function removes an epoch from your recording extractor.

        Parameters
        ----------
        epoch_name: str
            The name of the epoch to be removed
        '''
        if(epoch_name in list(self._epochs.keys())):
            del self._epochs[epoch_name]
        else:
            raise ValueError("This epoch has not been added")

    def getEpochNames(self):
        '''This function returns a list of all the epoch names in your recording

        Returns
        ----------
        epoch_names: list
            List of epoch names in the recording extractor
        '''
        epoch_names = list(self._epochs.keys())
        return epoch_names

    def getEpochInfo(self, epoch_name):
        '''This function returns the start frame and end frame of the epoch
        in a dict.

        Parameters
        ----------
        epoch_name: str
            The name of the epoch to be returned

        Returns
        ----------
        epoch_info: dict
            A dict containing the start frame and end frame of the epoch
        '''
        #Default (Can add more information into each epoch in subclass)
        if(epoch_name in list(self._epochs.keys())):
            epoch_info = self._epochs[epoch_name]
            return epoch_info
        else:
            raise ValueError("This epoch has not been added")

    def getEpoch(self, epoch_name):
        '''This function returns a SubRecordingExtractor which is a view to the
        given epoch

        Parameters
        ----------
        epoch_name: str
            The name of the epoch to be returned

        Returns
        ----------
        epoch_extractor: SubRecordingExtractor
            A SubRecordingExtractor which is a view to the given epoch
        '''
        if(epoch_name in list(self._epochs.keys())):
            from .SubRecordingExtractor import SubRecordingExtractor
            epoch_info = self._epochs[epoch_name]
            start_frame = epoch_info['start_frame']
            end_frame = epoch_info['end_frame']
            return SubRecordingExtractor(parent_extractor=self, start_frame=start_frame,
                                         end_frame=end_frame)
        else:
            raise ValueError("This epoch has not been added")

I think this is about right

The formatting gets a bit screwed up in the markdown (the paragraphs are off)

Done! I also made separate checks to make sure epoch names are strings throughout with value errors if not.
The getEpochInfo usage was clever!

I actually just realized it should probably return epochs in chronological order. So sort by earliest start_frame

Yes, that's better.


text:
[partial, required]: implement falsy masks and optional/nullable/nullish flavors

Closes https://github.com/colinhacks/zod/issues/2191 and https://github.com/colinhacks/zod/issues/2190
Previously a mask allowed you to to require/partialize only certain properties while leaving the others intact. I called such old behaviour thruthy masks because you selected the properties assigning a true value to them.
I implemented the opposite, meaning that you can require/partialize all properties except certain ones. I called this new behaviour falsy masks because you select the properties assigning a false value to them.
I've made care of making everything backwards compatible, with the small exception that you can't mix true and false values in the same mask anymore (previously false values were simply ignored) because that would be ambiguous: how should it behave, like a falsy or thruthy mask? I could theoretically treat it as a truthy mask and ignore falsy values but that would be a bad behaviour in my opinion because it wouldn't be intuitive. Also the breaking change is small enough because I see no valid reason why anybody would be mixing true and false values anyway.
Since we're at it I'm also forbidding empty masks (previously {} was a valid mask) because again it's not intuitive whether you should treat it as a truthy or falsy mask (I think that particular fix ended up in the second commit, but since I'm upstreaming both of them it shouldn't matter. I can rebase it into the first one if you prefer).
The second feature I'm upstreaming are optional/nullable/nullish flavors for partial and required. That depends on the previous commit because it implements such behaviour for both truthy and falsy masks. Previously partial transformed a field of type T into T | undefined while required transformed a field of type T | undefined into T. Since along with the optional method we also have nullable and nullish methods it makes sense to have nullable and nullish flavors of partial and required as well. Naming starts to get messy though, so I've decided to not add any more methods but instead select the "flavor" via parameters. I've made sure to keep everything 100% backwards compatible so the default is still the optional flavor and the number and the position of the parameters changes depending on the overloaded function: parameters get processed and mask and type get reassembled in the function implementation so this is completely transparent to the end user.
A nullable flavor of required will strip out ZodNullable instead of ZodOptional (T | null becomes T) while the nullish flavor will
strip out both ZodNullable and ZodOptional (T | undefined | null becomes T).
Similarly a nullable flavor of partial will wrap with ZodNullable instead of ZodOptional (T becomes T | null) while the nullish flavor will wrap with both ZodNullable and ZodOptional (T becomes T | undefined | null).
While bad behaviours are already enforced via typings (not mixing falsy and truthy masks, not passing empty masks which are ambiguous and cannot be discerned to a specific mask type) I also enforce these checks via type assertions (assertMaskIsNotMixed). While special care has been taken to optimize such function, a small (IMO negligible) performance impact is inevitable. If you prefer we can get rid of it and assume all our users will use TypeScript, but in my opinion it's better to keep it. I've also been careful to compute conditions outside of for loops to achieve some small performance improvements whenever possible, so I wouldn't worry about that.
I might have been over zealous  with the tests and they are probably too much and too many, but I didn't want you to get mad about testing every single possible corner case so the more the better. Feel free to cut them down as you see fit.
I still didn't update the documentation because I was looking for some feedback first. You didn't answer to my feature requests yet so I hope this will be enough to get your attention because I'd really love to have these features merged ASAP.
I'm currently working on a zod types generator so I will hopefully be able to test this on a larger project of my own soon. Tests are probably enough to cover every possible corner case, but the more testing the better.

I've manually updated my projects' zod types to make use of the methods introduced by this PR (instead of my custom helpers) and the resulting types still match with the database schema.
By the way we will probably want to rename assertMaskIsNotMixed to assertMaskIsValid and PartialType to FilterType or something else (because it's being used by both partial and required).

This is really extremely useful, especially in cases where a backend doesn't support (or doesn't want to) serializing non-existing (null) values to undefined (missing in json). I'd love to see this merged soon, because it would allow us to get rid of some ugly code.

because it would allow us to get rid of some ugly code

I know the feeling, in fact I have more things I would love to get merged but I'm waiting for this before pouring more time into tests/etc. With this PR, the automatic zod types generator that I've just finished and the remaining features which I'm currently shipping in my own zod fork I've basically cut down several hundreds lines of code into just a few dozens, plus I've uncovered several bugs. One of these additional features is built-in support for SQL UNIONs: whenever you need to UNION two different tables everything but the intersection must be nullable and it is extremely annoying and error prone having to do so manually.

Not stale, I'm still waiting for any kind of feedback from the maintainer.

ping @colinhacks

This is great stuff! Hope this gets reviewed soon.
If it isn't, it could be solely down to that wall of text in the initial post. Headings, bullet points, and code blocks go a long way - particularly for complex issues. Would be a shame to see this go to waste.

I've had a tremendous amount of trouble deciding what to do with this. For starters, it's a really well-made PR and it implements features that I think are useful. But there are some things that are giving me pause which I'll outline below. All told though, I'm going to close this, but I really appreciate the great work here @darkbasic, and the patience from everyone on this thread.
Modes
I don't like the idea of "modes" like PartialType generally, and usually I can think of an API that avoids them. (More on that later.)
Bundle size
I was hesitant to add this in v3 because it's a lot of code for a feature that isn't widely requested. Zod 4 will be redesigned to be more tree-shakable so this becomes a little more okay, but since most users will use ZodObject, these methods will end up in their bundle, even if unused.
What is "optional" anyway?
Zod 4 will make a distinction between different types of "optional". There's the "question mark" flavor ({name?: string}) and there's the "or-undefined" flavor ({name: string | undefined }). In Zod 4 you'll be able to specify one or the other  flavor (or both) when defining object schemas. Any API that deals with partial/required needs to be able to handle that distinction. It's tricky.
Here's a rough initial proposal for the set of "partial" APIs. All of these optionally accept (truthy) masks.
const schema = z.object({ name: z.string() });

schema.partial();  // { name?: string | undefined }
schema.partial.except({ ... }) // equivalent of falsy masks

schema.allow.empty(); // { name?: string }
schema.allow.undefined(); // { name: string | undefined }
schema.allow.null(); // { name: string | null }
schema.allow.nullish(); // { name: string | null | undefined }

The proposed set of "required" APIs. All of these optionally accept (truthy) masks.
const schema = z.object({ name: z.string().optional().nullable().or(z.undefined()) });
// { name?: string | undefined | null }

schema.required();  // { name: string }
schema.required.except({ ... }) // equivalent of falsy mask

// mask supported but optional
schema.not.empty(); // { name: string | undefined }
schema.not.undefined(); // { name?: string | null }
schema.not.null(); // { name: string | undefined }
schema.not.nullish(); // { name?: string }

Optionality is complicated. Whatever ends up landing in Zod 4 will be quite a bit different from this PR. I don't feel that good about my proposal either. I'll keep this all this in mind as I rethink things for Zod 4, maybe something more elegant will materialize.
Thanks again @darkbasic! And feel free to chime in with thoughts.

Thanks for reviewing my PR, even if you didn't end up accepting my changes in the end.
Unfortunately I don't have the time right now to discuss eventual API changes, but I'd like to add my two cents about its utility.

I was hesitant to add this in v3 because it's a lot of code for a feature that isn't widely requested

I suspect that this feature is of particularly high value to library/tools developers rather than end users.
In particular as a mikro-orm collaborator I've written a typings generator that creates a zod schema from the ORM entity definitions, with the goal of generating slonik types via the ORM metadata to manually write composable SQL queries that are type safe at runtime and build time:
https://github.com/mikro-orm/mikro-orm/discussions/5102#discussioncomment-8076746
https://the-guild.dev/blog/accounts.js-1.0-rc#about-me
It relies on this feature for which I'm currently maintaining my own zod fork, which is the main reason why I haven't released it yet.
That being said, even if its main utility would probably be limited to libraries/tooling developers, I can still see 11 hearts just in this PR, which is massive wall of text that would scare 90% of the users just by the sheer size of it.

authors: colinhacks darkbasic nicktrn osdiab t-animal

repo: colinhacks/zod


text:
Add Remotion as Bronze sponsor

We love Zod!
It powers the ability to define any schema and then visually edit the props in our sidebar (example).
We barely have any other dependencies, but Zod is just perfect and think is gonna be useful forever, no matter how many hypecycles we go through. Thanks for making this!

If you don't mind, we'll add ourselves to the list of sponsors, been one since April.

Oh no! Sorry Jonny, this slipped through the cracks. Thank you for your sponsorship 🙏

Thanks a lot 😃 No worries, I know you've been busy making awesome stuff 🙌🏼

authors: JonnyBurger colinhacks


text:
suggestion /missing feature

Hi,
i want to use your PID Control for a PV Power Control.
The Range is 0 to 100,
50 is 0W feed in /out
0 is > 2kw feed out
100 >2kw feed in
but my problem is, that at night or when its shady the PID runs away and get very high values. So my only solution is a bad simple P Control....
Maybe i thought of implementing a limit for the output.
Can you realize something like that? That would be perfect for me!
Thanks

Sorry, I don't fully understand, remember I am not familiar with how your power system works.
What are you measuring that is used as the input to the pid (the PV)?
What does the output control?
What is the setpoint value?
Also show me how the pid node is configured.
Also attach a chart showing the pv and output values over a period.

sorry for wasting your time, i mixed up two different pid controllers and ended up at the wrong github. Please delete it (i cant)

If you are having problems with integral runaway, which is what this sounds like, then I suggest you try this node, as it has logic to prevent that happening.

authors: colinl nickeeey

repo: colinl/node-red-contrib-pid