stateChanged Observable

Hi, you could make this Observable type T ?, it is so that it is more type safety

Hi Mailok. Thanks for the suggestion. If the exact state defined with ObservableStore was always returned we could do that, However, Observable Store also allows a stateSliceSelector function to be defined that allows custom state (a "slice" of the overall store for example) to be returned. So, we need to leave any to accommodate that feature...at least for now.
I could see a potential change to public stateChanged: Observable<T | any>; but I'd need to look into any ramifications of making that change on existing projects. Seems pretty safe on the surface, but would need to experiment more. Something I'll add to the list to research though as soon as I have some free time. Appreciate the suggestion.

@DanWahlin You are welcome.

Thanks again for the suggestion. After thinking this through more I came to the conclusion that there's not a great way to change that while still supporting the new state slice feature (at least without introducing some new concepts). Since the state parameter returned from stateChanged can be typed, that solves the issue when no state slice function is defined and when one is defined so I'm going to leave that for now.
As enhancements are made in the future I'll keep this in mind though. Thanks!

@DanWahlin - I put together a small stackblitz to test out using Partial<T> as a possibility. I 'm able to get intellisense and it still updates only the properties a developer provides. I added a readme.md to point out some of the changes.  Would love to get your thoughts and submit a PR if it helps.
https://stackblitz.com/edit/observable-store-partial-r-and-d?file=foo.store.ts


Translating CEL ordering/filtering to REST API requests

The filtering/ordering of the responses when using gRPC is handled by CEL expressions. We need to investigate how this function can be used while consuming the REST endpoints. Followup from discussion in the Slack: https://tektoncd.slack.com/archives/C01GCEH0FLK/p1677743586629099

If this is possible to use CEL expression in REST requests?
If yes, how? Document the process and update OpenAPI Spec.
If no, alternatives. May need a new feature to be added.

/help

I had the same issues and it took me some time to setup the REST calls with filtering and pagination, even though pagination doesn't work properly as I understood.
There is definitely need for more documentation and examples. Also how to access over REST.

Hey @manuelwallrapp, it would be great if you can share your findings and what topics you think are missing. I am actively working on better documentation for Tekton Results. You can see #377 for debugging using REST and API docs.

Thanks for sharing. I will look into all other queries as well and include them in the API docs.

Hi @manuelwallrapp, can you please review #377, and suggest if something is missing/should be added, and also if it covers this issue?

The issue was resolved in #377


Resuming TPE experiment crashes tuner

Environment:

NNI version: 2.1
NNI mode (local|remote|pai): local
Client OS: Ubuntu 20.04.2 LTS
Python version: 3.8.8
PyTorch/TensorFlow version: tensorflow==2.4.1
Is conda/virtualenv/venv used?: conda
Is running in Docker?: no

Log message:

dispatcher.log:

[2021-04-13 20:15:24] INFO (hyperopt.tpe/Thread-1) tpe_transform took 0.002890 seconds
[2021-04-13 20:15:24] INFO (hyperopt.tpe/Thread-1) TPE using 164/164 trials with best loss 0.029564
[2021-04-14 08:25:02] INFO (hyperopt.utils/MainThread) Failed to load dill, try installing dill via "pip install dill" for enhanced pickling support.
[2021-04-14 08:25:02] INFO (hyperopt.fmin/MainThread) Failed to load dill, try installing dill via "pip install dill" for enhanced pickling support.
[2021-04-14 08:25:02] INFO (nni.runtime.msg_dispatcher_base/MainThread) Dispatcher started
[2021-04-14 08:25:02] INFO (nni.tuner/MainThread) Load checkpoint ignored by tuner, checkpoint path: /home/arvoelke/nni-experiments/vYc2JOFN/checkpoint
[2021-04-14 08:25:02] INFO (nni.assessor/MainThread) Load checkpoint ignored by assessor, checkpoint path: /home/arvoelke/nni-experiments/vYc2JOFN/checkpoin
[2021-04-14 08:25:02] INFO (hyperopt_AutoML/Thread-1) Importing data, current processing progress 0 / 93
[2021-04-14 08:25:02] ERROR (nni.runtime.msg_dispatcher_base/Thread-1) 'NoneType' object is not subscriptable
Traceback (most recent call last):
 File "/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni/runtime/msg_dispatcher_base.py", line 88, in command_queue_worker
   self.process_command(command, data)
 File "/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni/runtime/msg_dispatcher_base.py", line 147, in process_command
   command_handlers[command](data)
 File "/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni/runtime/msg_dispatcher.py", line 119, in handle_import_data
   self.tuner.import_data(data)
 File "/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni/algorithms/hpo/hyperopt_tuner.py", line 496, in import_data
   self.receive_trial_result(parameter_id=_parameter_id,
 File "/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni/algorithms/hpo/hyperopt_tuner.py", line 359, in receive_trial_result
   json2vals(self.json, vals, out_y)
 File "/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni/algorithms/hpo/hyperopt_tuner.py", line 127, in json2vals
   json2vals(in_x[key], vals[key], out_y,
 File "/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni/algorithms/hpo/hyperopt_tuner.py", line 118, in json2vals
   _index = vals[NodeType.INDEX]
TypeError: 'NoneType' object is not subscriptable
[2021-04-14 08:25:07] INFO (nni.runtime.msg_dispatcher_base/MainThread) Dispatcher exiting...
[2021-04-14 08:25:08] INFO (nni.runtime.msg_dispatcher_base/MainThread) Dispatcher terminiated

What issue meet, what's expected?:
Expected to be able to resume an experiment that had been stopped. Instead it crashes the tuner.
How to reproduce it?:
nnictl create ...
<restart the computer after a number of trials have completed>
nnictl resume <expID>

Additional information:
Using the TPE tuner and the medianstop assessor.
Computer was forcefully shutdown after trial 164 (see time gap in above log). It is unknown whether this issue also occurs when the experiment is stopped manually. The nnimanager.log includes some more information around the time of the shutdown:
[2021-04-13 20:15:35] INFO [ 'Trial job peyrP status changed from WAITING to RUNNING' ]
[2021-04-13 20:15:35] INFO [ 'Trial job im1GH status changed from WAITING to RUNNING' ]
[2021-04-13 20:15:35] INFO [ 'Trial job j7qc2 status changed from WAITING to RUNNING' ]
[2021-04-13 20:15:35] INFO [ 'Trial job jAM2J status changed from WAITING to RUNNING' ]
[2021-04-13 20:17:25] INFO [ 'Change NNIManager status from: RUNNING to: STOPPING' ]
[2021-04-13 20:17:25] INFO [ 'Stopping experiment, cleaning up ...' ]
[2021-04-13 20:17:25] ERROR [ 'Dispatcher error: write EPIPE' ]
[2021-04-13 20:17:25] ERROR [ 'Error: Dispatcher stream error, tuner may have crashed.\n    at EventEmitter.dispatcher.onError (/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni_node/core/nnimanager.js:550:32)\n    at EventEmitter.emit (events.js:198:13)\n    at Socket.IpcInterface.outgoingStream.on (/home/arvoelke/anaconda3/envs/*/lib/python3.8/site-packages/nni_node/core/ipcInterface.js:42:72)\n    at Socket.emit (events.js:198:13)\n    at errorOrDestroy (internal/streams/destroy.js:107:12)\n    at onwriteError (_stream_writable.js:430:5)\n    at onwrite (_stream_writable.js:461:5)\n    at _destroy (internal/streams/destroy.js:49:7)\n    at Socket._destroy (net.js:614:3)\n    at Socket.destroy (internal/streams/destroy.js:37:8)' ]
[2021-04-13 20:17:25] INFO [ 'Change NNIManager status from: STOPPING to: ERROR' ]
[2021-04-14 08:25:01] INFO [ 'Datastore initialization done' ]
[2021-04-14 08:25:01] INFO [ 'RestServer start' ]
[2021-04-14 08:25:01] INFO [ 'Construct local machine training service.' ]
[2021-04-14 08:25:01] INFO [ 'RestServer base port is 8080' ]
[2021-04-14 08:25:01] INFO [ 'Rest server listening on: http://<IP_ADDRESS>:8080' ]
[2021-04-14 08:25:02] INFO [ 'NNIManager setClusterMetadata, key: trial_config, value: {"command":"srun -G1 -pGPU1,GPU2 --mem=16G python *.py","codeDir":"/home/arvoelke/git/*/nni/."}' ]
[2021-04-14 08:25:02] INFO [ 'Resuming experiment: vYc2JOFN' ]
[2021-04-14 08:25:02] INFO [ 'Change NNIManager status from: INITIALIZED to: RUNNING' ]

I've left out the other parts of the logs as they don't appear to include any additional information.

I tried this again with nnictl stop (instead of a sudden restart) and encountered the exact same issue.
I also tried pip install dill as recommended in the logs, but that did not help.
I took a brief look at the code where the error is being reported, and I'm wondering if it maybe the tuner reloading does not support nested search spaces? Or perhaps choices with only one option? My search space JSON file looks like:
  "batch_size": {"_type": "choice", "_value": [500]},
  "activation": {"_type": "choice", "_value": ["relu"]},
  ...,
  "layer_params2": {
    "_type": "choice",
    "_value": [
      { "_name": "None" },
      {
        "_name": "LMU",
        "units": {"_type": "quniform", "_value": [16, 1024, 1]},
        "memory_d": {"_type": "quniform", "_value": [1, 64, 1]},
        "order": {"_type": "quniform", "_value": [3, 64, 1]},
        "theta": {"_type": "uniform", "_value": [1, 1280]}
      }
    ]
  },
  ...

Can you provide full experiment config? I have tried following config and the issue did not reproduce.
searchSpace: {
    "batch_size": {"_type": "choice", "_value": [500]},
    "activation": {"_type": "choice", "_value": ["relu"]},
    "layer_params2": {
        "_type": "choice",
        "_value": [
            { "_name": "None" },
            {
                "_name": "LMU",
                "units": {"_type": "quniform", "_value": [16, 1024, 1]},
                "memory_d": {"_type": "quniform", "_value": [1, 64, 1]},
                "order": {"_type": "quniform", "_value": [3, 64, 1]},
                "theta": {"_type": "uniform", "_value": [1, 1280]}
            }
        ]
    }
}
trialConcurrency: 3
maxTrialNumber: 10
trialCommand: echo hello
tuner:
    name: 'TPE'
    classArgs:
        optimize_mode: maximize
trainingService:
    platform: local

I was able to reproduce it with the following setup.
test.json
{
    "layer_params": {
        "_type": "choice",
        "_value": [
            { "_name": "None" },
            {
                "_name": "LMU",
                "units": {"_type": "quniform", "_value": [16, 1024, 1]},
                "memory_d": {"_type": "quniform", "_value": [1, 64, 1]},
                "order": {"_type": "quniform", "_value": [3, 64, 1]},
                "theta": {"_type": "uniform", "_value": [1, 1280]}
            }
        ]
    }
}

test.py
import time

import nni

time.sleep(10)

params = nni.get_next_parameter()
nni.report_final_result(1)

test.yml
authorName: ABR
experimentName: test
trialConcurrency: 1
trainingServicePlatform: local
searchSpacePath: ./test.json
useAnnotation: false
tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: minimize
  includeIntermediateResults: true
trial:
  command: python test.py
  codeDir: .

Steps to reproduce:

nnictl create --config test.yml
Wait for one trial to successfully complete, and the next one to start running.
nnictl stop
nnictl resume <expID>
Wait for dispatcher to enter error state.

For step 2, it seems important that the next trial has to have started running when nnictl stop is issued. If the stop is issued at the perfect moment between trials then the bug does not appear to occur. I've only tested it 2-3 times in each condition though, so not 100% sure.

@liuzhe-lz ^ ^

TPE tuner has been rewritten.


Handle QuestionNotFoundError

These exception can be raised if the errors map returned by the API contains keys that are not recognised by the content loader.

:+1:


[SPARK-19397] [SQL] Make option names of LIBSVM and TEXT case insensitive

What changes were proposed in this pull request?
Prior to Spark 2.1, the option names are case sensitive for all the formats. Since Spark 2.1, the option key names become case insensitive except the format Text and LibSVM . This PR is to fix these issues.
Also, add a check to know whether the input option vector type is legal for LibSVM.
How was this patch tested?
Added test cases

Test build #72143 has started for PR 16737 at commit 297f87a.

Test build #72143 has finished for PR 16737 at commit 297f87a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72143/
Test PASSed.

Merged build finished. Test PASSed.

cc @cloud-fan @yhuai @dongjoon-hyun

Oh, then, are these the last piece of the case-sensitive options?

+1. LGTM except one typo! @gatorsmile

I think LIBSVM and TEXT are the last two built-in sources that do not support case sensitivity.

Test build #72238 has started for PR 16737 at commit c2c145d.

Test build #72238 has finished for PR 16737 at commit c2c145d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72238/
Test PASSed.

Please hold on this PR. Found a serious bug to fix in case insensitive option support.

what is the bug?

: ) When @sureshthalamati tried to fix the docker test failure in Oracle, he found the new code change in Spark 2.1 makes JDBC option key values always lower case. However, Oracle's connection properties are case sensitive. Thus, the changes caused the regression.
However, we realized the data source resolution always set the options to lower cases, as discussed in https://github.com/apache/spark/pull/14773. Thus, I think it is safe to do it, but we need to document the workaround if users hit this issue for JDBC sources. @sureshthalamati is doing it.
Thus, this PR is ready to review. Thanks!

Test build #72476 has started for PR 16737 at commit 07beaad.

Test build #72476 has finished for PR 16737 at commit 07beaad.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72476/
Test PASSed.

Test build #72528 has started for PR 16737 at commit ec6eb6e.

Test build #72528 has finished for PR 16737 at commit ec6eb6e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72528/
Test PASSed.

Merged build finished. Test PASSed.

LGTM, merging to master!


Bonobo Git Server uses UUID for repository IDs

Bonobo Git Server uses UUID to identify repositories.
My remote origin is like this
[remote "origin"]
        url =<EMAIL_ADDRESS>
${tool.protocol}//${gitorigin.hostname}${gitorigin.port}${gitorigin.path}${tool.commitpath}${hash}
And the webview commit url looks like this:
http://git.local/Bonobo.Git.Server/Repository/Commit/13a15c5a-b4e1-407c-a011-f4f34ac74747?commit=6d6582febf4f01e5fe22021b3d2bfe616a1bbdb5
This is what the extension generates by default.
http://git.local/Bonobo.Git.Server/MyRepository/commit/6d6582febf4f01e5fe22021b3d2bfe616a1bbdb5
Is there a way to translate MyRepository to the correct UUID that Bonobo uses?
Something like
"translations": {
    "MyRepository": "13a15c5a-b4e1-407c-a011-f4f34ac74747",
    "MyRepository2": "98267044-947d-4bf5-9893-7d0a290255da",
    "MyRepository3": "30da658f-94f7-4b7d-867f-6acf974e43f3",
  },

Thanks.

Hey David! Thanks for the feature request.
I am not a big fan of adding features for singular services. The solution you propose looks a lot like having a workspace setting for each repository. It can even be committed with the code allowing many users to share the URL with the UUID "baked" in.
Would that be a workable solution?

Yeah, that´d be enough.


iOS wrong reference resource folder for splashScreen png

I have done everything according to manual and it works fine on both platforms. However, when I reinstall all packages with 'yarn' command on iOS I see error:
CopyPNGFile<EMAIL_ADDRESS><EMAIL_ADDRESS>(1 failure)
After changing png file in module folder everything is ok again, but I would like rather have reference to my asset folder that is not ignoring by git.
Any way to achieve that?

Having a couple of issues, there are debug and release options under Project > Build Settings > Header Search Paths, and entering $(SRCROOT)/../../../react-native/React resolves to an absolute directory in Xcode.

Should we add to both debug and release, and is it ok that Xcode resolves the absolute directory path considering it's a shared project?


Kappa prioritizes Mojang capes over OptiFine capes

If you have both an OptiFine and a cape from Mojang (migrator, minecon, etc..) it will prioritize the Mojang cape over OptiFine, only showing the OptiFine cape after disabling the Mojang one in the launcher skin settings
would it be possible to maybe add a config option to switch the priority to OptiFine?

No, this is intended behavior. Kappa prioritizes official capes because they're official, and OptiFine capes shouldn't even exist if you go by the commercial usage guidelines.


test(dtslint): add elementAt

Description:
This PR adds dtslint tests for elementAt.
Related issue (if exists): #4093

Pull Request Test Coverage Report for Build 7362

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.2%) to 96.967%

Files with Coverage Reduction
New Missed Lines
%

src/internal/observable/fromPromise.ts
1
87.5%

src/internal/observable/fromIterable.ts
2
95.24%

src/internal/observable/fromObservable.ts
2
83.33%

Totals

Change from base Build 7359:
0.2%

Covered Lines:
5786

Relevant Lines:
5967

💛  - Coveralls


question regading the isoseq cluster2 parameters

Hello,
I am curious if it is possible to alter the cutoff of the 5', 3' overhang for isoseq cluster2.
I know the current cutoffs are <100bp 5' overhang,  <30bp 3' overhang, <10bp gaps. Is it possible to loosen the cutoff to something like < 200bp 5' overhang.
Thanks!
Laur

Sure, try --overhang-5 200

thanks for the quick reply!
I believe I can do a similar thing if I want to alter the 3' cutoff. It would be great if these options are listed in the help page. when I run isoseq cluster2, I only see the following:
Usage:
  isoseq cluster2 [options] <flnc.bam|xml|fofn> <transcripts.bam>

  flnc.bam|xml|fofn  STR   Input flnc BAM, ConsensusReadSet XML, or FOFN
  transcripts.bam    STR   Output transcripts BAM

  --singletons             Output FLNCs that could not be clustered.
  --sort-threads     INT   Number of sorting threads per BAM file. Equivalent to open file handles per BAM.
                           Defaults to -j. [0]
  --write-bam        STR   Write annotated BAM file.

  -h,--help                Show this help and exit.
  --version                Show application version and exit.
  -j,--num-threads   INT   Number of threads to use, 0 means autodetection. [0]
  --log-level        STR   Set log level. Valid choices: (TRACE, DEBUG, INFO, WARN, FATAL). [WARN]
  --log-file         FILE  Log to a file, instead of stderr.

Thanks again for the help!
Laur


Tidy up examples

Regenerate all examples, and give a script for doing so in the future. I want to create an archive of graphs so I can keep testing against different versions.
I haven't regenerated all Ruby graphs, as this is blocked by https://github.com/oracle/graal/pull/3524.
Also fix the issue with node source info.

I haven't regenerated all Ruby graphs, as this is blocked by oracle/graal#3524.

Wouldn't it be better if Ruby graphs used Primitive.blackhole (to make value escape, but without the noise from a non-inlined call, similar to assigning to a field in Java), and for the graph which specifically wants to show non-inlined calls just disable inlining altogether?

Ah, https://chrisseaton.com/truffleruby/basic-truffle-graphs/ already uses Primitive.blackhole, I either forgot or did not see it yet :)
So opaque_call and instance_call are the two non-inlined  on purpose methods left.


Frontend: Assign actions to people outside an evaluation

Awaiting this till v2.
2 options

Change models.cs to have actions with answeredBy = azureUniqueId instead of Participant
Add participant when assigning actions to non-particpipant person.

Awaiting this till v2.
2 options

Change models.cs to have actions with answeredBy = azureUniqueId instead of Participant
Add participant when assigning actions to non-particpipant person.


add EditorConfig styles for java, xml and yml files

I dont know if you are interested by: http://editorconfig.org/ but I find it very useful for collaborative projects.
It's not as thorough as https://github.com/joel-costigliola/assertj-core/blob/master/src/ide-support/assertj-eclipse-formatter.xml because EditorConfig works on raw files, but it allows developer to start working on projects without having to import specific settings.
It's enabled by default on many editors (jetbrains suite, GitHub web editor) and plugins are available for almost every other IDE: http://editorconfig.org/#download

it's pretty basic but if it makes contributors life easier then it's all good.

Merged in 2.x - thanks

You're welcome.
Is there a reason you didnt merge on master?

Hi Michael,
I'm obviously not Joel, but I guess I can answer your question.
Joel currently works on assertj 2.4.0 in the 2.x branch. So he merges everything not java 8 specific into 2.x. When work on 2.4.0 is finished Joel merges the commits into master and continues with 3.4.0.

Okey, that makes a lot of sense, thanks for the explanation!
On Sat, Jan 16, 2016, 13:25 Pascal Schumacher<EMAIL_ADDRESS>wrote:

Hi Michael,
I'm obviously not Joel, but I guess I can answer your question.
Joel currently works on assertj 2.4.0 in the 2.x branch. So he merges
everything not java 8 specific into 2.x. When work on 2.4.0 is finished
Joel merges the commits into master and continues with 3.4.0.
—
Reply to this email directly or view it on GitHub
https://github.com/joel-costigliola/assertj-core/pull/573#issuecomment-172197954
.

Thanks @PascalSchumacher  I forgot to answer this one


Integrate Python logging module into all .py files of Quantifying + README Update for Logging

Fixes

Fixes #85 by @naishasinha
Description
This pull request incorporates an efficient method to use logging within all Python files, keeping in mind the possibility of shared modules. I've also added an update to the "Resources" section in the README with a link to the logging section of the Python docs that other contributors can reference to if they need help with any aspect of the module.
In addition to replacing all the current print() statements with logging, I've also added descriptor LOG.info() statements within the start of each function so that when being logged in the terminal, it's easier for the contributor to understand which function is being debugged.
Technical details

Multiple calls to LOG (which is a variable stored from getLogger()) will return a reference to the same logger object, both within the same module as well as across modules
This was the general logger setup for all files. As it is consistent among all files, it makes it easier to access and reference among shared modules:

Set up the logger
Define both the handler and the formatter
Add formatter to the handler
Add handler to the logger
Log the start of the script execution

Other notes:
The Handler object is responsible for sending the logs to different destinations, and the Formatter object determines the order, structure, and contents of the log message. Having these objects will make it easier to log between shared modules.
Tests

Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main or master).
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no
visible errors.

Developer Certificate of Origin

For the purposes of this DCO, "license" is equivalent to "license or public domain dedication," and "open source license" is equivalent to "open content license or public domain dedication."

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

looking good! just a few requested changes

Thank you for the feedback @TimidRobot! I just updated the exception handling in all of the files (base code shown below), which 1. replaces the e.code line using an f-string instead, 2. Keeps the (130) and/or (1) in the LOG.info() statements, and 3. I made sure to include the traceback in the log statements as well. Please let me know if I need to fix anything else!
if name == "main":
# Exception Handling
try:
main()
except SystemExit as e:
LOG.error(f"System exit with code: {e.code}")
sys.exit(e.code)
except KeyboardInterrupt:
LOG.info("(130) Halted via KeyboardInterrupt.")
sys.exit(130)
except Exception:
LOG.error(f"(1) Unhandled exception: {traceback.format_exc()}")
sys.exit(1)

Please fix last f-string and resolve static analysis errors

@TimidRobot I believe the current static analysis errors in my version are due to the code not aligning with pre-commit, I'll fix those and also pull changes from merge conflict resolution by tonight

@TimidRobot I've fixed all the static analysis errors and have also pulled changes from merge conflict resolution! Please let me know if there's anything else I need to do. Thank you for your patience!

There's a few more static analysis errors to resolve
./dev/tools.sh

isort
Loading .env environment variables...
Skipped 1 files

black
Loading .env environment variables...
reformatted /Users/timidrobot/CreativeCommons/git/quantifying/wikipedia/wikipedia_scratcher.py
reformatted /Users/timidrobot/CreativeCommons/git/quantifying/google_custom_search/google_scratcher.py
reformatted /Users/timidrobot/CreativeCommons/git/quantifying/visualization/visualization_engineering.ipynb

All done! ✨ 🍰 ✨
3 files reformatted, 15 files left unchanged.

flake8
Loading .env environment variables...
./deviantart/deviantart_scratcher.py:7:1: F401 'datetime as dt' imported but unused
./metmuseum/metmuseum_scratcher.py:8:1: F401 'datetime as dt' imported but unused
./vimeo/vimeo_scratcher.py:11:1: F401 'datetime as dt' imported but unused
./wikicommons/wikicommons_scratcher.py:8:1: F401 'datetime as dt' imported but unused
./youtube/youtube_scratcher.py:8:1: F401 'datetime as dt' imported but unused

or
pipenv run pre-commit run -a

Loading .env environment variables...
check for added large files..............................................Passed
check python ast.........................................................Passed
check for case conflicts.................................................Passed
check docstring is first.................................................Passed
check that executables have shebangs.....................................Passed
check json...............................................................Passed
check for merge conflicts................................................Passed
check toml...............................................................Passed
check yaml...............................................................Passed
detect destroyed symlinks................................................Passed
fix end of files.........................................................Passed
mixed line ending........................................................Passed
trim trailing whitespace.................................................Failed
- hook id: trailing-whitespace
- exit code: 1
- files were modified by this hook

Fixing wikipedia/wikipedia_scratcher.py
Fixing google_custom_search/google_scratcher.py

Black....................................................................Passed
Flake8...................................................................Failed
- hook id: flake8
- exit code: 1

deviantart/deviantart_scratcher.py:7:1: F401 'datetime as dt' imported but unused
wikicommons/wikicommons_scratcher.py:8:1: F401 'datetime as dt' imported but unused
metmuseum/metmuseum_scratcher.py:8:1: F401 'datetime as dt' imported but unused
youtube/youtube_scratcher.py:8:1: F401 'datetime as dt' imported but unused
vimeo/vimeo_scratcher.py:11:1: F401 'datetime as dt' imported but unused

isort....................................................................Passed

@TimidRobot Fixed!


migrate from k8s.gcr.io to registry.k8s.io

Signed-off-by: Paco Xu<EMAIL_ADDRESS>Kubernetes migrated to registry.k8s.io since https://github.com/kubernetes/kubernetes/pull/109938.
I'm not sure if contained should migrate to it in this release cycle 1.7. Or at least, pause image should migrate to registry.k8s.io .
Some context can be found in

https://github.com/kubernetes/k8s.io/wiki/New-Registry-url-for-Kubernetes-(registry.k8s.io)
https://github.com/kubernetes/enhancements/blob/master/keps/sig-release/3000-artifact-distribution/README.md
https://github.com/kubernetes/kubernetes/pull/110350
https://github.com/kubernetes/kubernetes/issues/110471

the k8s project is moving away from k8s.gcr.io to registry.k8s.io.

registry.k8s.io is currently redirecting to k8s.gcr.io
in 1.25 we should switch kubeadm's code to use registry.k8s.io by default.
k8s.gcr.io will continue working (for some time) by redirecting to registry.k8s.io

/cc @dmis

@pacoxu Let's land this here closer to the k8s 1.25 release and not before. is that fair? thanks!

@pacoxu Let's land this here closer to the k8s 1.25 release and not before. is that fair? thanks!

OK.
We meet a problem in kubeadm/kinder e2e test on the latest kubeadm on the old kubelet(n-1 version). The problem is for the loaded image is gcr image and kubeadm is using registry.k8s.io(kinder needs to load the image before using it.). We should take attention to similar issues. Details in https://github.com/containerd/containerd/pull/7038.

@pacoxu ack, let's see if we can fix it on kinder side?

I found that https://github.com/kubernetes-sigs/kind/pull/2688 is adding this repo as a mirror of the other.

This will cause kind to pull from registry.k8s.io first before k8s.gcr.io directly if that fails.

@dims
kubernetes v1.25 is out.


Remove @_spi(ExperimentalLanguageFeature) from BodyMacro

Function body macros have been accepted.

@swift-ci Please test

@swift-ci Please test


Delete .import/ folder and update gitignore

The .import/ folder should not be committed, which is why it goes in the .gitignore, but it seems this was committed before the .gitignore file existed. I deleted these files.
I also updated the .gitignore to have .mono/ and other misc ignores. .mono/ is important because it generates in any project opened by the Mono version of Godot, even if that project does not use C#.

Thanks @aaronfranke :+1:


lomiri: init at unstable-2022-12-21

Description of changes
Continuation of https://github.com/NixOS/nixpkgs/pull/108366
Fixes https://github.com/NixOS/nixpkgs/issues/99090
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Was superseded by #292872.


Remake spawInShell to use built-in terminal

spawnInShell actually doesn't work on Linux - since there is no concept of starting process that brings its own console window like in Windows, instead we should use terminal API to provide same UX on all OSes.

I am not sure to understand what spawInShell is. I tried to search from github in this repo and Ionide helpers but found no results.

https://github.com/ionide/ionide-vscode-helpers/blob/master/src/Helpers.fs#L204


Establishing a  "workspace" on the platform

User stories

Right now our users have to navigate between profiles, and find within them the parts of those profiles that are 'active'. For administrators and people working across a number of Collective, projects, and events this can be quite inefficient and irritating.

There's not a clear separation between the 'working' parts of Open Collective (filing, approving and paying expenses) and the 'profile' parts of Open Collective (my Collective, organisation, personal profile).

For example to file an expense for /opensource I have to go to the profile page and find the right button, instead of having a 'file an expense' button on my (logged in) dashboard at opencollective.com. This is different from an exploratory experience where I might be searching or browsing for projects to support or events to attend etc.

The single-entity approach to navigation and UX is providing a very fractured experience for users who interact with a number of Collectives, as a supporter, contributor or administrator. We see ourselves building fixes for specific problems like showing all your submitted expenses in one place https://github.com/opencollective/opencollective/issues/3749.

I (most users on the platform but most prominently fiscal host and collective admins and increasingly platform support providers) do increasingly more frequent and regular work on the platform. This requires me to navigate to different places on the platform and often use multiple open tabs in order to find what I need to do and the information I need to do it. It would help me to have a centralized place that presents to me everything that needs my attention (work I need to do) together with the tools I need in order to respond (do to the work).

Best solution for this problem
The purpose of this pitch is to outline a first design & engineering effort to kickoff a campaign for establishing the workplace experience on the platform. The desired outcome is an easily addressable place (URL) on the platform in which a user can peer into and act on all things Open Collective. The objective is to create an appealing new place with minimal disruption to the existing user experience. This will make it possible to refine existing tools and introduce new ones to flesh out the "workplace" experience.
MVP
Goals for this initial effort:

Create the workplace “page” on the platform with an existing sidebar-workspace UI pattern including a decision on a simple and memorable URL, eg:

my.opencollective.com
app.opencollective.com
opencollective.com/me
opencollective.com/admin
opencollective.com/home

Consolidate into it existing user-centered functionality that is currently “housed” in the “my account” control that appears for logged-in users in the top-right corner.

News & Updates (transform from modal pattern to list+modal pattern).
My Contributions (accommodate the function of the existing sidebar in this interface – perhaps resolved by a context switcher? – see below).
My Expenses (does not have a sidebar so should integrate easily).
My Transactions (does not have sidebar so should integrate easily).
User Settings
Help
Logout

Add a Context Switcher – Question: do we want to add (in this phase) a context switcher (as prototyped by Gustav)?

Update the user launcher (top right corner) to reflect these changes and connect the user to the new “workplace.”

Integrating UX Patterns
The proposal is to embrace a sidebar-workspace UX pattern already applied to collective administration:

This pattern is also already present in the individual user settings page:

The proposal is to embrace this pattern but to populate it with the existing user-centered tools that are currently in the “my account” control:

Resulting in something that looks like:

And as this pattern merges with the existing collective administration pattern, a “profile switcher” can be added to make it easy for the user to navigate between the personal profiles and other collective profile in which they are involved (while keeping in mind that the intention is, in the future, to minimize the need for a user to switch profile by bringing integrated tools to the user workplace, instead of sending the user to seek tools):

Boundaries
In a conversation with @gustavlrsn (who has already been experimenting with a similar transformation) we propose that this be initially developed as an internal application where:

The team (and invited users) can access and experience this interface.
We can make a clear decision (at any point in time) if and what to release openly.
We can continuously evolve and experiment with the contents of the workplace as we expect this project to unfold over numerous development cycles.

There are many potential new tools and enhancements of existing tools that will move into the "personal workplace" experience. The priority in this scope of work is to establish this place in order to be able to gradually enhance it in the future. Therefore the focus should be on transitioning existing tools into it with as little disruption as possible without getting dragged into additional work.

Engineering goal this week:

[ ] Implement a first iteration and deploy as a preview on Vercel

Goal for this cycle (from Tuesday's check-in/kick-off)

[ ] 1. Introduce the admin panel sidebar pattern for USERs, and include existing User tools there

Stretch goals

[ ] 2. Enable this pattern for all Collective types
[ ] 3. Enhance profile/collective/context switching UX

Step 1 deployed on Vercel:

Deploy that will not change (can be used to compare changes/review progress later)

https://opencollective-frontend-dqhr2y4hv-opencollective.vercel.app

Deploy that will stay in sync with the branch

https://opencollective-frontend-git-feat-workspace-opencollective.vercel.app

Connected to the staging API, login works

If or how we merge this to production we can decide together. An idea could be to put it behind a feature flag or simply on a URL not linked in the UI, if we don't want to spend time polishing something for production at this stage. Or skip merging it and test against a separate Vercel deploy.

This week

[ ] 2. Enable pattern for all Collective types
[ ] 3. Introduce switcher in sidebar

Week 6

[ ] Finalize, review & deploy https://github.com/opencollective/opencollective-frontend/pull/8751 as a hidden feature

[ ] Fix some filtering bugs (links to old page structure)
[ ] Restore menu links so that /dashboard is only available through the URL
[ ] Use new expenses/transactions page components for existing pages

Basically moving the filtering logic from /pages to /components to allow reusability across pages

[ ] decide on release approach —  @gustavlrsn @iamronen perhaps alpha release (quietly) to staff for feedback
[ ] user testing — complete 'script', goals and prompts

2023 Cycle 3
FYI we're continuing this project for the next six weeks, the goals are:

Optimizing sidebar navigation:
a. Review naming & merging of existing tools  (eg: Contributions in collectives).
b. General layout review
Figure out what shows up when you land in a workspace (personal, collective, host, etc.).
Handling Removed archived events and projects from the switcher
URL’s (How are we going to set up the URL structure?)
Header & footer and integration within the website
a. Clarify branding (use formal version of the graphic language)
Changes to the existing “my account” top-right corner control:
a.Integrate & direct to workspace.
b. Decide what to do with “News & Updates”

From the pitch:
We completed an MVP that included the implementation of the admin panel for all profile types. Before we had the admin panel (the feature dashboard + the settings with a left sidebar UI pattern) activated only for Fiscal Hosts.
We want this pattern to be the center of the experience using the Open Collective platform going forward, it feels a big change so that’s why we are doing it gradually, with the aim to test every step of the implementation process.
For this next step we want to establish this sidebar UI pattern with more detail, with the goal of building the infrastructure that’s going to support feature development that is key to the overall experience, like the onboarding work, scheduled to continue next sprint cycle as well; and a lot of other opportunities we are eager to tap into using the workspace as base.

This week

[ ] kick-off sync with engineering, design & product to figure out what to fix before first release

Kickoff Summary
attended @gustavlrsn @Memo-Es @tomsusemihl
It is important to note that the outcome of this project is a change that will effect all logged in users who after this release, when going to opencollective.com be directed to their individual workspace instead of to the public home page.
The two largest tasks to making this happen are:

Figuring out where an individual should land? what is the "homepage" within the individual workplace? During the kickoff we agreed that the effort during this cycle may yield two outcomes:

A low-cost MVP solution for this release
A pitch for a more elaborate solution for next cycle (that cannot fit into the appetite for this cycle)
Potentials include:
- An introduction to the workplace itself and how to get around with the switcher
- Updates?
- Recent expenses/transactions/contributions?
- Collectives that I am a member of?

A "Contributions" tool for collectives (see #6217 ) that includes:

Tabs for selecting between incoming and outgoing contributions
Filters (eg: one time , recurring tiers)
List of contributions (in a list format similar to expenses NOT in cards) which includes the contributor email (this has been asked for by collective admins, is available in the API and was probably not added to the information on the collective page for security reasons, but now we are inside the individual workplace of a collective admin who has the right to access this information)

Engineering centered efforts

When you login to or arrive at Open Collective you should be directed to your individual workspace instead of the public pages
Deciding on URL mapping (should be user friendly and memorable) The current proposal is opencollective.com/dashboard. I think something like opencollective.com/admin can be better since "dashboard" is just one page in the admin. Tagging John to consult on this choice.

Design centered efforts:

Mapping the tools we currently have (for individual/collective/fiscal hosts/organizations) into the workspace sidebars (including moving around, renaming, etc.) owner @Memo-Es
Adopting the header and footer to the workspace
Creating a clear pathway from the workspace to the public website
Changing the existing "my account" control in order to integrate with the workspace.

Work Agreements

Because everyone is already engaged with other projects we agreed on two phases of work:

Individual (diverging) phase - for the remainder of week 2 (current) and week 3 everyone is going to work undisturbed (with minimal to no need to coordinate) on their own, at their own pace and time. Everyone is going to starting with clear and easy wins and preparation of proposals for the things that do require collective work and decision making.
Collective (converging) phase - a sync meeting will be schedule for the beginning of week 4 during which everyone will share/demo the work that they've done. There we will start working in a coordinated way to integrate the individual efforts and to being a coordinated effort to bring the project to completion by the end of the cycle.

@tomsusemihl will initiate and coordinate agile user testing during the cycle to collect feedback on some of the design choices. This may take place during both phases. During the collective phase we will prioritize rapid iteration between design, prototyping and testing.

When you login to or arrive at Open Collective you should be directed to your individual workspace instead of the public pages

Warning, this is not the desired experience in many cases, if you were here to do something (do a contribution, submit an expense) and were asked to sign in, you want to continue whatever you were working on, not directed to something else.

Thank you for that discernment @znarf
The "default redirect change" is for the homepage only.
Other usecase specific redirects should not be affected by this change.

The project is mostly paused this week.

Engineering review has indicated that this may involve more scope/risk that anticipated.
Reschedule mid-cycle sync call

Just having a quick chat with @iamronen about the consistency/divergence of expense pages within workspace separate from the entity.
Firstly, the workspace needs to reflect the expense currently being viewed in its URL structure as we (admins) will need to share those URLs with one another if reviewing together. IF the URL is shared with a non-admin it's reasonable to expect that the user is redirected to the public page for that expense.

to add notes from yesterdays meeting (my take, please update if necessary):

we dont yet have a good picture of what the landing page for the workspace will look like
it's unlikely that we'll have time to implement a landing page now, but we will look at it once it's ready
we will, at the very least, have the landing page ready for a future sprint.

I wanted to add, although I didn't have energy for it at that time, that I think there's a quick win interim 'landing' page using the activity feed that could get us to being able to release something more complete.
The reason I am so attached to this is that the activities table includes things like coments created, collective contacts etc that could be a part-solution to many of the issues identified in #5501.

@BenJam, a couple of clarifications and my own take of yesterday's meeting about the workplace implementation:

We decided NOT to launch anything this cycle, but we are implementing what we can  for internal testing purposes
We took this decision after realizing the work and dedication everyone put on the expense crunch left us with little time to tackle a big project like this one
The workplace home (I prefer home and not landing page because landing page has a marketing feeling for me at least) is scheduled to be designed this cycle in the first version, as in having simplicity as the main goal and improving it from there. It has been like that since the beginning; what changed is the commitment to the public launch.
This leaves us two weeks to nail down the design definition and put up a live prototype for us to test and reflect on during the buffer week before the next cycle.
My goal for this week is to discuss during the demo the important aspects of this definition:

Workplace home design proposal
UI set + layout (Navbar, footer, main navigation)
Sidebar definition proposal (For all entities)

Next week would be about working on the prototype along with @gustavlrsn and starting testing it towards the EOW

Also, where can I see what the activity log looks like for user activity?

Yesterday we have a review conversation with @Memo-Es @gustavlrsn @BenJam and myself.
In the first part of the conversation Gustav presented his "Jobs to be done" analysis around how workspace fits into the overall platform:

Despite the analytical starting point we ended up in a diverging and opinionated conversation about if/how the workplace pattern should be differentiated from the public website (marketing pages and collective profiles using custom header and footer. This is still not resolved.
In the second part of the conversation we focused on the "individual workspace landing page." This is where, when workspace is released, users who login to the platform will arrive. We reached a unanimous agreement that a "timeline experience" is the way we want to go and will be made the top priority. Any additional elements on this page (shortcut boxes, how-to's will be secondary to this core experience.
The timeline will be based on the activity log information we already have at hand and we will merge into it additional things like collective update. The timeline will create a "social feed" experience letting the user know about the latest relevant happenings on the platform. From the timeline the user will be able to quickly link to other places on the platform (expenses, collectives, etc.).

great convo last week, some details to smooth out on the design/ux side

[ ] @Memo-Es and @tomsusemihl to iterate on design/UX

Link to updated Excalidraw layout option added: https://app.excalidraw.com/s/3CgxXzZv6l4/1pIWpuOjPis

just to leave @Memo-Es' notes on our conversation last week:

Synthesis of the call about the next steps for the worskspace implementation:

Priorities

Nail down the home design
Design solution for the new contributions tab

Consensus reached

Top navigation
Profile switch logic

Following tasks

Nail down what elements of the top navbar we will show
Review activity types and narrow down the list to what we are showing, designing the elements that may be missing
Review how the sidebar elements will be displayed (How many, what elements, merging some, etc.)
Tables design
Implement the final visual style
Set up a testing path and follow ups after launch

to which i wanted to add that, in my opinion, we should reserve the table view as an opinion (with a quick interface picker) for pro users. Meaning when viewing the expenses list, and possibly when looking at the context of a host organisation.

Scopes and tasks identified during the cycle4 kickoff:
Workspace (Logged In) UX Pattern

[ ] Implement the template for the agreed pattern:
[ ] Implement header
[ ] Implement header account control
[ ] Implement sidebar + profile switcher
[ ] Implement footer
[ ] Decide on the contents of the top-bar
[ ] Decide how search should behave in the top-bar
[ ] Decide on terminology: Workspace / Dashboard / other
[ ] Figure out how to integrate into (or next to) the profile switcher links to public profile pages.
[ ] Decide on a “contextual memory” strategy:
[ ] Option 1: When I am looking at expenses in one profile and switch to another I am still looking at expenses.
[ ] Option 2: Remember what is the last thing I looked at in a given profile and when I switch to it go there

Timeline in Individual Profile

[ ] Decide which activities from the activity logo should show up in the individual timeline
[ ] Decide what options should be available in the timeline filter
[ ] Implement the timeline
[ ] Prepare simulation profiles:

Contributor to a few collectives
Contributor + expense submitter
Contributor + expense submitter + fiscal host admin
Contributor + expense submitter + collective admin of one collective
Contributor + expense submitter + collective admin of numerous collectives
Contributor + expense submitter + collective admin of numerous collectives + fiscal host admin

[ ] Implement a profile impersonation capability (tool for the team only) to be able look at the timeline through the eyes of actual platform users (that correlate to the profiles we want to test).
[ ] Test timeline using profile impersonation
[ ] Conduct user testing with a few users

Collective Contributions Page

[ ] Create an initial proposal for a collective contributions page

Timeline in Collective Profile

[ ] Decide which activities from the activity log should show up in a collective profile.
[ ] Implement a profile impersonation of actual collectives to test the timeline in the collective context

Timeline in Fiscal Host Profile

[ ] Decide which activities from the activity log should show up in a fiscal host profile.
[ ] Implement a profile impersonation of OC hosts to test the timeline in the fiscal host context

NOT include in the scope of this cycle:

notifications
add/create button

@jpjhill I feel like we could benefit from your voice in the copy conversation around what to call this place workspace/dashboard ... something else?

Engineering specs/issues from engineering sync with @kewitz today
Workspace UX Pattern

[ ] Implement logged-in top navigation
[ ] Simplified profile dropdown
[ ] Implement sidebar + profile switcher
[ ] Implement simplified footer
[ ] Redirect from / to /dashboard (and last opened account context)
[ ] Save last opened Dashboard context (account) in local storage
[ ] Integrate link(s) to public profile(s) from Dashboard/Account switcher

Timeline

[ ] Decide which activities from the activity log should show up

[ ] Individual
[ ] Host
[ ] Collectives

[ ] Decide what options should be available in the timeline filter
[ ] Implement the timeline resolver
[ ] Update frontend to match design
[ ] Implement ability to view timeline as another user (only for root users)

Contributions page

[ ] Implement outgoing/incoming filter to "Recurring contributions" page

@jpjhill I feel like we could benefit from your voice in the copy conversation around what to call this place workspace/dashboard ... something else?

One aspect that surfaced in the engineering sync was that while "Workspace" could feel more correct/accurate than "Dashboard" for fiscal host admins, it could be more out of place for casual contributor type of users that are not working on the platform

As an extra comment, calling this "My workspace" or "admin workspace" will require us to change the terminology in the docs, where I believe it is currently called a Fiscal Host Dashboard https://docs.opencollective.com/help/fiscal-hosts/fiscal-host-dashboard
Just leaving this here as a note to self as much as anything, as that will need updating if we decide to go with workspace

@jpjhill thank you!

For example, Google Workspace collects a lot of different tools which helps you manage your work, ranging from making video calls to scheduling appointments and doing email marketing. A lot of apps and platforms tend to use the "dashboard" to showcase trends in data-vis form. One exception is Wordpress, which sends editors, etc, to its "Admin Dashboard" which allows you to manage posts, comments and plugins and so on.

Noting here that Google Workspace is product name for a suite of tools as opposed to the admin section inside on of the apps. They even use "Dashboard", "Admin Dashboard"  and "Admin Console" to refer to this part of Google Workspace:

I'm sure there are other cases of apps/platforms using "Workspace" to refer to a page or section of a platform, and would love to see those here, but to me it seems most used when referring to the currently selected "account context" or the ones I can pick from, like here in Monday.com:

One exception is Wordpress, which sends editors, etc, to its "Admin Dashboard" which allows you to manage posts, comments and plugins and so on.

Stripe is another example of a platform using "Dashboard" to mean administrative dashboard (as opposed to a metrics dashboard): https://dashboard.stripe.com

(As an aside, I've noted Memo's suggestion to name it "my workspace". I reckon that's fine, assuming that the workspace is tied to the individual user (ie. I am an admin who runs this host and maybe other hosts and related things) rather than to a specific host (in which case it would probably be more "host workspace"). As I presume the workspace is tied to the individual logged-in user/admin, this is acceptable and feels more like "I am doing things as an admin in this area" rather than "I am acting as a named host")

The dashboard/workspace will have a switcher where you can change the context from your individual profile context to a host/collective/org you're administrating
https://github.com/opencollective/opencollective/assets/1552194/7a124ed7-edf0-4e06-b7a3-23aca24b099e
To me "My Workspace" seems to imply a singular workspace when in fact you can choose from many.

@jpjhill & @gustavlrsn thank you for digging into this, it helped me clarify some thoughts:

Gustav seems to be pointing to a hierarchy:  the "Dashboard" is a container for numerous "Workspaces" (one being my individual workspace, others for collective and/or hosts I am a member of).
Grasping that hierarchy gave me a sense of order which feels right.
However I want to suggest we reserve the word "Dashboard" for the "place where I can get an overview" experience ... we already have a beta version of a fiscal host dashboard which I assume we will continue to evolve ... I think there is justification for us to explore in the future a "collective dashboard" which gives you an overview of a collective.

So I want to propose this integrating hierarchy:
Admin

Personal Workspace

Timeline
& other tools

Collective Workspace

Collective Dashboard
& other collective tools

Fiscal Host Workspace

Fiscal Host Dashboard
& other fiscal host tools

However I want to suggest we reserve the word "Dashboard" for the "place where I can get an overview" experience ... we already have a beta version of a fiscal host dashboard which I assume we will continue to evolve ... I think there is justification for us to explore in the future a "collective dashboard" which gives you an overview of a collective.

Our current usage of "Host Dashboard" refers to the whole admin section, and the page you're referring to is called "Reports":

Which is also what Stripe is also doing:

To me "Reports" makes sense - and a better place for the most basic overview type of stats would be the "Home" section (next to or above the activity timeline), making those overview stats much more accessible than having to go to a sub page called "Dashboard".

@gustav what is presented in Stripe when you click on "Reports"?
I don't think this exemplifies clarity in language.
What we show under Reports is more like a dashboard.
We don't really have reports in the platform (though the accounting and finances inquiry processes may surface needs for some).
I think we do have reports, but that they exist in Metabase.

@iamronen there are a few reports to choose from, one of them looks kind of similar to what we have (they also have reports that are more tabular/text based)

I think renaming "Reports" to "Dashboard" would seem slightly out of place, whatever name we choose for the workspace/admin dashboard. "Dashboard" sort of implies a starting place, home or overview - not something to be found too deep within the navigation (unless it is a link to a standalone thing and represents it's own starting place)

Here's my proposal of a hierarchy of terms for the top navigation and sub-nav

Dashboard

[Personal account] <-- account switcher

Home
Expenses
...
Settings

[Collective account]

Home
Expenses
...
Reports
Settings

[Fiscal Host account]

Home
Expenses
...
Reports
Settings

Explore <-- renamed from "Discover"/"Discover Collectives" to not confuse with discover.opencollective.com + avoiding two words starting on "D" next to each other
Help & Support

This week

https://github.com/opencollective/opencollective/issues/6827
Sync on approach for "Contributions" page

An extensive and detailed conversation yesterday led to an agreement on the "Workspace (Logged In) UX Pattern" scope of work. We made some assumptions that helped us converge:

We are leaving in the logged-in-header both the Explore (which takes you to the collective search page) and a modal Search (which responds quicker without having to wait for a page load). We acknowledge that these perform the same function, but as with the existing website, they are duplicates that we are currently keeping for performance reasons.
We have recognized potentials to differentiate the two search options and to provide more value in the modal search. These potentials are aligned with the workspace experience but are not in the scope of this cycle. @gustavlrsn has expressed an interest in prototyping and demo'ing some of these potentials. While this may happen during this cycle it will likely lead to enhancements in future cycles.
We are keeping the "resources" control that @Memo-Es has demo'ed but whittling it down to minimal contents (to avoid functional duplication) and a minimal implementation  (no hierarchical scrolling within the modal).
We are re-instating the "fire updates" indicator but will consider changing it to reduce the sense of urgency that the fire-metaphor evokes.
We are keeping a minimal top-right-corner "account control." We will include in it some copy explaining to users that the things they are used to finding are now in their personal workspaces and the profile switcher.

@iamronen is integrating the conversations and opinions about terminology into a research proposal.
attn @jpjhill your assistance would be much appreciated in:

The copy for the above mentioned (#5) account control.
Update to documentation that both explains  the new user experience and addresses the changes users may experience.

We agreed to aim to complete the integration of the whole Workspace UX pattern by the end of this week so that next week @Memo-Es can perform usability tests with both internal team members and a few external team members.
A followup sync conversation is scheduled for today for the "timeline" and "contributions" scopes of work.

The "master task list" for this project has been updated to reflect the tasks that surfaced from the "timeline" and "contributions" scopes.
Timeline:

We have a solid initial timeline implementation (some performance and design issues still to be resolved).
The value of the timeline became clear during this demo - the experience of information assimilated for you:

Being able to see your expenses progress through the pipeline without having to go anywhere (not to expenses in your account, or expenses in the collective...)
Being able to see updates from collectives I contribute to - without having to visit the different collective pages.

We want to review what the timeline looks like for sample users on the platform ( @kewitz has created a mechanism for this and @Memo-Es will put it to use). After internal reviews reach out to feedback from internal team and a few external users.

Contributions:

We all feel better at a tabular format of expenses separated into recurring and one-time.
We need to figure out the page layout for recurring and one-time.
We need to figure out how to present incoming and outgoing (and recurring and one time within each) for collectives.

Proposal for a general pattern for tabs and filtering in the workspace
I'm proposing to adopt a general tabs/filtering pattern for the workspace (that came out of some expense pipeline prototyping).
Might document this a bit more in text but recorded a loom here for now:
https://www.loom.com/share/2ac48905ef4649278f98e9543566fa15
Prototype available at https://opencollective-frontend-git-tailwind-ui-opencollective.vercel.app/dashboard/opensource

This week

[ ] Merge https://github.com/opencollective/opencollective-frontend/pull/9014
includes:

simplified profile menu (includes Resources)
search button in header (with key shortcut)

[ ] Review design of and implement some link to profile
[ ] Sync on proposed tabs/filter pattern

This Week

[ ] Check design updates and implement them
[ ] Ship timeline for Orgs and Collectives?

During an engineering sync we have agreed that:

The "contribution" scopes are higher priority then the timeline in collectives and hosts.
That the new contributions page can be a transitional "landing page" for collectives.
That the new expenses, with the expense pipeline can be a transitional "landing page" for hosts.

And, given where we are in the cycle, and the added complexity we are encountering in tabs&filters (an aspect of Workspace that emerged in the Expense Pipeline project) we opted to divert @kewitz to start working on contributions (starting with the personal (individual) contributions page.
attn @Memo-Es

outcomes of sync between @gustavlrsn and @Memo-Es
https://www.loom.com/share/aaa1ed6cc4fe45578cc250e9fea53565

This week

[ ] design review of https://github.com/opencollective/opencollective-frontend/pull/9047
[ ] merge navigation update

This week

[ ] Wrap up and merge Contributions user dashboard view

[ ] Add missing Filter components

[ ] Work on Contributions collective dashboard view

The following is a proposed release plan for the Workspace project.
Context
The workspace changes the logged-in experience for all users. Before workspace users typically arrived at the public landing page. After workspace, users will directed to either a personal workspace (where they can find tools related to them personally) or a workspace for a collective, organization or fiscal host (where they can find tools related to that context).
Workspace is a major transition in user experience. It will lead into a transitional period during which users will adjust to the new experience and we continue to improve, enhance, replace and create new tools that were not possible before we had the workspace pattern.
We have not been able to perform enough user testing to validate the changes we've made and how they come together in a whole new user experience.
Once workspace is out we will be able to build out solutions that depend on it. Two immediate examples that are being considered are the onboarding experience and expense submission. However, we cannot make changes that depend on Workspace until it is ready for full public (not optional) release.
Included in Workspace
1: A UX pattern that includes a:

A modified header
A sidebar that includes a context switcher + tools
A work area populated by selected tools.

2: An individual timeline experience that delivers  to the individual user updates regarding their expenses, contributions and updates from collectives they contribute to.

3: An updated "account control" in the top-left corner of the header that was planned to be more minimal but we ended up repopulating (and in doing so creating some duplication of the switcher) in order to reduce the disruption to two core usecases (quickly accessing collective to which I submit expenses & upcoming events).

4: An updated site navigation control in the top-right corner of the header that places navigation elements in a side-drawer and creates a "bread-crumb" presentation in the header to help orient the user into where they are and what they are seeing. An immediate value in this pattern is that when you view an event, you can see that it is within a collective and which collective it is.

Proposed Release Plan

By the end of this cycle we release Workspace as an internal beta to which all team members can opt-in.
We use the remaining time of this cycle to gather feedback from internal team members.
At the end of this cycle we assess if we want to open the beta to additional users (this can be additional fiscal hosts, a sample of end users ... this is yet to be determined). An engineer with database access can provide finely targeted beta access.
We use the first half of the next cycle to perform usability and research tests and assessments.
We use the second half of next cycle (when @gustavlrsn will be once again available) to make additional changes based on the feedback we collect.
We aim for full release at the end of next cycle (cycle6) opening the door work workspace-dependent projects.

pinging @znarf @BenJam @gustavlrsn @@kewitz @Memo-Es @tomsusemihl @jpjhill @shannondwray for feedback on the release plan and additional release consideration.

On Tuesday (July 4th) we had a call discussing the status of the Workspace project and its release-readiness.
In attendance @Memo-Es @tomsusemihl @kewitz @gustavlrsn @jpjhill @shannondwray and myself. The conversation began around language but inevitablybranched out and touched on the project from many directions.
The conclusions we came to (to which no one expressed any objection) were:

The change we are making is desirable, it already greatly improves the platform experience, we see more potential to improve it and it opens the door to many more changes and additions that will continue to improve the platform experience.
We agreed to draw a hard boundary that changes to this project do not leak out into the public website and logged-out experience. We recognize that some of the navigational changes we are making in this project may benefit the public website but will consider such changes at a later time and separate from this project.
The project is already released as an internal beta (OC Inc and first party hosts have access to it).
The most vulnerable part of the project is the multiplicity of navigational UI affordances (site navigation in the top-left corner, account control in the top-right corner and the profile switcher inside workspace). Each of these serve a purpose (none of then are sporadic additions) but the experience for an end-user will likely create confusion about what to look for and what to do where.
Some of the multiplicity and confusion carries over from lack of clarity that exists in the existing user interface and our desire to create a low-friction transition since this change is something that, when released fully, will affect all platform users.
During the meeting @tomsusemihl created and shared a mockup that demonstrated a potentially integrated navigation experience.  This struck a chord (especially with @shannondwray who represented the non-power platform users).
We agreed to make an effort in the time remaining in this cycle to do another iteration that focuses on the navigation challenge. This will be led by @Memo-Es and @tomsusemihl . We also agreed that if this effort does not yield clear results, we are all OK with moving ahead with a beta-release as-is.
We are targeting the middle of next cycle (cycle 5 - end of week 3) to arrive at an assessment point about the readiness for launch of the workspace experience.
We would like to reserve resources for the 2nd half of cycle 5 to make additional changes in order to improve the release readiness of the project so that we can do a full release at the end of cycle5.
We want to use the remaining time of this cycle and half of next cycle to do more extensive user research and testing. Initially this effort will focus on the internal team and then expand beyond the team to users who have not been involved in any way with the work we've done on the workspace experience and platform transition.
John will use the time between now and then to create documentation and release notes that will support users in the transition.
John and Shannon will also work on communicating to the community that we are working on the Workspace experience. They will coordinate this effort with Memo & Tomas to decide if we want to use this as an opportunity invite people to try the new workspace. What this will actually look like is not yet clear:   - If the timing is right we may be able to simply shift the project into a public beta so that anyone can test it and give feedback.   - Another option is to invite people to explicitly ask for participating in some kind of beta testing process which will require additional coordination and shaping by Memo & Tomas.
Numerous people on the team have expressed a wish to provide a more explicit feedback mechanism specifically for this transition. This is still an unknown.

Week 6 goals

[ ] Correct navigation pattern and push it to the beta version
[ ] Set up testing path @tomsusemihl

Cycle 4 Summary
During this the workspace unfolded guided by two forces: engineering and design:

Engineering proposed a more "advanced" modality aimed at power users. It combined navigation (menus), orientation (breadcrumbs) and the profile switcher into a unified interface.
Design proposed a more "simplified" modality aimed at more lay users which provided a more gradual transition from what currently exists into the Workspace UX pattern.

Engineering-led prototypes were built out and could be experienced directly while design-led prototypes were created in Figma and were less tangible.
We performed a few demo-interviews (with internal team members) as user testing to compare the two directions. The initial feedback indicated that we are heading in a good direction and the new designs were well received. However, it was clear that the navigational patterns (top-left navigation, top-right account control and profile switcher in the sidebar) were competing with each for user attention other and causing confusion for users who were not sure where to look for what.
Internal user testing
The following things were noticeable in the interviews:

Looking first to the “account control” as the "default profile switcher" - probably because of the popularity of the account control as a UI pattern and because that is where users currently go on the platform.
When the profile switcher was embedded in the header (in the engineering prototype) it was harder for users to find and therefore did not function well as an orientation mechanism - both answering the question “where I am right now” and “how do I go somewhere else”.
Also in the engineering prototype, users attention was drawn more to the sidebar and less to the horizontal menu. Therefore when users were asked to find something (contributions or expenses) they first looked to the sidebar and there encountered secondary information (eg: recently visited collectives) instead of the primary tools they need. This was likely also due to the fact that the existing platform UX patterns also have these tools in the sidebar.
The horizontal menu, while more effective in terms of screen real-estate seemed less visible to users and therefore else effective. Reference article: https://www.nngroup.com/articles/vertical-nav/
In the design-led prototype we were still left with some tension between the two navigation controls - the “account control” and the “profile switcher.” This is a very specific situation for users who only have their profile (such as contributors and expense submitters who do not are not admins of any other entities on the platform) and therefore do not need to switch profiles.

Conclusions from testing

Continue with the design-led option as a starting point. It is a simpler user experience that offers a smoother transition from what where we currently have.
Within that we explored two options for dealing with the tension between the account control and the profile switcher:

One solution we explored for this was to integrate the profile switcher into the account control. This caused somewhat of a disassociation between the “where am I” (now in the account control - top-right corner of the header) and the “what I can do here” in the sidebar. We opted to leave the two controls separated.
An improvement we may explore in the future is to altogether hide the profile switcher for users who do not have profiles to switch. We cannot do this right now because the affordances for creating collectives and organizations are embedded in the profile switcher. If we create alternatives for these affordances that are not dependent on the profile switcher it will be possible to remove it completely for users who only have one workspace context. This will clarify and simplify the experience for such users.

Produce a short tutorial video in the spirit of “welcome to workspace” that will introduce the new workspace and guide users through typical scenarios within workspace. When workspace is released, all logged-in users will land on their individual workspace page that will have this video.
Include a feedback mechanism integrated into the platform dedicated (at this point in time) to user feedback specifically about Workspace and their experience transitioning to it.

Intentions for Cycle 5

Design is using the transition week to apply finishing touches and a full spec for the workspace.
The project will be prioritized early in the cycle so that within a few days (hopefully no later then the end of week1 - because most of the elements have already been built out, the work is mostly a re-assembly and touching up) we have an updated working beta version that can be used for external testing.
We will then take 2 weeks of external user testing for feedback from users who have never seen workspace and would encounter it for the first time.
Depending on our confidence and readiness (ability to collect and integrate feedback), we may also open the workspace up as a public-beta so that more users can opt-in to try it.
This will leave us 3 more weeks of the cycle for drawing conclusions and doing a last round of fixes and improvements.
During the cycle we will also:    - produce the “welcome to workspace” tutorial video (owner @Memo-Es )

produce documentation (owner @jpjhill )
produce release notes. (owner @jpjhill )
produce a more pronounced announcement (newsletter? blog?) about the workspace release and its significance to the platform (owner @jpjhill )

Scopes of work for Cycle 5
Scope 1:  Engineering implementation of uUpdated beta version
(Extracted from latest loom from @memo)

[ ] Header: Workspace / Explore navigation controls
[ ] Account Menu: two column + footer implementation with "my account" on the left and "my collectives/organizations/upcoming events on the left. Degrade gracefully into one column for users (eg: contributors or expense submitters) who do not administer any collectives / organizations and have not purchased tickets for any upcoming events.
[ ] For logged in users add to the marketing pages a control to get them back to the workspace in the top-right side of the header.
[ ] Include "Add" controls in the profile switcher (for collectives and organizations)
[ ] Implement mobile adaptation (including new bottom navigation element for switching between workspace & explore)

Scope 2: Formulate a user research plan

[ ] tbd

Scope 3: Executing User Research

[ ] tbd - based on research plan

Scope 4: producing a short introduction video to Workspace

[ ] tbd

Scope 5: Documentation & Release Notes

[ ] tbd

[ ] Leo to continue pragmatically implementing UX/design changes
[ ] @tomsusemihl to finalise user testing plan

Test plan:

[ ] Cherry picked users list from @BenJam
[ ] Schedule calls (invite via slack, email, etc)
[ ] Run tests
[ ] Analyze with team and iterate
[ ] Release it with announcement

Week 5 update

[ ] Finish onboarding module
[ ] Start taking tests

[ ] Merge pending navigation wrap-up: https://github.com/opencollective/opencollective-frontend/pull/9250
[ ] Merge Contributions and Contributors page

I propose the following Workspace menu re-organizations:

On Individual Workspaces

Move Payment Methods from Settings to the main workspace menu BEFORE transactions

On Collective Workspaces - BEFORE Transactions in this order

Move Team from Settings to the main workspace menu
Move Tiers from Settings to the main workspace menu
Move Virtual Cards from Settings to the main workspace menu

On Fiscal Host Workspaces AFTER Reports(beta) in this order

Move Tiers from Settings to the Organization main menu
Move Team from Settings to the Organization main menu

On Event Workspaces BEFORE transactions in this order

Move Tiers from Settings to the Event main menu and rename to: Sponsorship Tiers
Move Tickets from Settings to the Event main menu.
Move Team from Settings to the Event main menu.
Move virtual cards from Settings to the Event main menu.

On Project Workspaces BEFORE Transaction in this order

Move Tiers from Settings to the Project main menu.
Move Team from Settings to the Project main menu.
Move Virtual Cards from Settings to the Project main menu.

@iamronen it might be best to communicate these with a lil video recording to make sure that we get the pickups right, but I'll let @kewitz ask if clarification is needed.
Meanwhile, @znarf and I had aroll through and we found a few issues that could do with snagging before releasing:

The Open Collective logo on the homepage should link to the workspace if the user is logged in
The workspace filter should separate 'hosts' from organisations as they have different experiences
The 'workspace' link that appears on the homepage should be moved to the user menu to keep
the 'create organisation/collective' buttons are entirely missing if you do not have any of those entities present in the menu.

we also noticed an inconsistency with the breadcrumb navigation between https://opencollective.com/octobox (showing logo / octobox) and the workspace (showing logo / workspace) we thought it would be best to show the current workspace in the URL i.e. logo / workspace / octobox

@BenJam

The 'workspace' link that appears on the homepage should be moved to the user menu to keep (consistency?)
I think in this case, the "Workshop" link is better off more visually present since it's now the base of the platform experience. I'm adding examples of stripe, cal.com, and coda

the 'create organisation/collective' buttons are entirely missing if you do not have any of those entities present in the menu.
I think this one is already fixed.

About the 'Explore' main navigation button
We talked about this during the first cycles of design+development where I thought it was a repeated action to go to the explore tab in the early version put up by Gustav AND also have the search icon to launch the quick search box. The difference we decided upon was the use case because you don't have a way using the search lightbox to (duh) explore collectives you don't know the name of.
Explore also defines a mode of using OC just as "Workspace" is a mode "Explore" is designed to be another mode and all the public profile pages exist within.
All this said I would love to have the discovery app take over the "Explore" mode soon :)

cc @znarf @iamronen

I think in this case, the "Workshop" link is better off being more visually present since it's now the base of the platform experience.

I don't see it "more visually present": it's on the right, instead of being on the left in non-marketing pages. It would be more visually present if it was looking like a button.
Stripe (and similar) are not good references because they have only 2 universes: marketing and app/dashboard. At Open Collective, we now navigate between 3 universes: marketing, public and dashboard. It's more complicated and transition between the 3 universes are generally more common than Stripe. I strongly recommend to keep the same navigation patterns across the 3 universes (position, look and feel, behavior).

logo and link on the logo
link to dashboard/workspace
link to explore (if we keep it)
search

Navigation full picture
I've put together the vision on which the current version of the workspace operates and what I understand from @znarf comment:
https://www.loom.com/share/7bd498a9c1774810881dbc87127ab38c?sid=567c7266-0fe2-489c-8c50-22976a48f4cd
@BenJam @iamronen

What I'm pushing for is to have a consistent navigation all the time for signed in users, including marketing pages.
I'm not necessarily pushing to add "Marketing" as a "mode" in the navigation. Alternatives: 1) no  "Marketing" or "Marketing" links for signed in users 2) we keep the Solutions/Product/Company links but the rest of the navigation stay consistent.

I think we should go for alternative 2 because we are not displaying the Solutions/Product/Company options anywhere else. For the record, earlier in the project I proposed to put these links under a "Resources" menu somewhere inside the account menu.

This week

[ ] merge UX update https://github.com/opencollective/opencollective-frontend/pull/9296

I propose the following Workspace menu re-organizations:

attn: purple indicates items that also need to be renamed.

@iamronen I think these make sense, except for "Info" (or renamed to "About") which is the edit collective form. What is the motivation to make it the default Collective dashboard page?

Navigation update
If the goal is to have the homepage featuring the same navigation as everywhere else when the user is logged in:

Note: Neither the Dashboard nor the Explore tabs will be selected.
We need to make accessible the options to navigate through our marketing pages

Option A
Option B

Add the options in the footer
Add a menu inside the user dropdown menu

@znarf @iamronen @gustavlrsn

@Memo-Es adding the options in the footer seems like the better option to me (that is where I would expect to find such links)
The lower part of the profile menu I'd like to consider removing, it seems too busy to have three areas of this profile dropdown with menus in different directions.
Privacy & Terms are available in the footer of the page already, the link to Open Collective Homepage we could move up inside the left column if we feel it's necessary to have another way to get to it beyond the footer?

About the menu organization
https://www.loom.com/share/cab94a06e7004d519b2d157a48834eaf?sid=afc5da9e-9eb4-4588-a60c-80df4e92db26
Design file
https://www.figma.com/file/ZQBMWhnGGtRWeIZknFW1eP/[OC-Design]-Production-Ready-✅?type=design&node-id=20939-14236&mode=dev
cc @gustavlrsn @iamronen

@iamronen has posted release plan
call tomorrow with @jpjhill and @shannondwray re: release communication
compiling future work into pitched for future cycles

Closing this as we did it!


Check that include/exclude files exist before starting backup

If any of the files listed in the include and exclude configuration files do not exist, the relevant backup program will abort, possibly in a broken state (e.g. lock file created but not removed). To prevent this, each backup wrapper should read in the list of files and check if they exist, aborting with an error if one is missing.

Fixed in 81bfd208b704afba78c14b0309d36f6e0548b6ca


error in get_features_duplicated.r

hi here,
> train_categorical <- fread(file.path(data_dir, "train_categorical.csv"), data.table=FALSE,
+ 							na.strings="", showProgress=TRUE,colClasses=colClasses, drop="Id")
Read 1183747 rows and 2140 (of 2141) columns from 2.494 GB file in 00:05:39
Error in .subset2(x, j) : subscript out of bounds

i'm getting this error here, how can avoid that?
> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.4

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] dplyr_0.5.0       dtplyr_0.0.2      plyr_1.8.4        digest_0.6.12     magrittr_1.5
[6] data.table_1.10.4

loaded via a namespace (and not attached):
[1] compiler_3.4.0   R6_2.2.1         assertthat_0.2.0 DBI_0.6-1        tools_3.4.0
[6] tibble_1.3.1     Rcpp_0.12.10     rlang_0.1.1

thankkks: )

Thank you for your report. I locate cause of trouble.
With newer data.table::fread we cannot use colClasses option and drop option simultaneously.
Please modify code like this.
https://github.com/toshi-k/kaggle-bosch-production-line-performance/commit/b663b7397da0162bc09f85fb2eff580fa1140446#diff-1723f610f4354d461b349411aff360e2
Don't use drop option, please remove columns after reading data.

thanks so much. i'm going to use this code in my term project. i can send it to you if you want to check it out.
cheers :)


Using on a Wemos D1 Mini - wifi config wont start

This is what I get when I try to start into config mode straight after flashing:
ESP8266 IR Controller
Config pin GPIO16 set to: 0
*WM: settings invalidated
*WM: THIS MAY CAUSE AP NOT TO START UP PROPERLY. YOU NEED TO COMMENT IT OUT AFTER ERASING THE DATA.
mounted file system
*WM: Adding parameter
*WM: hostname
*WM: Adding parameter
*WM: passcode
*WM: Adding parameter
*WM: port_str
*WM: Adding parameter
*WM: user_id
Using Static IP
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: <IP_ADDRESS>
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0
*WM: SET AP STA
Entered config mode
<IP_ADDRESS>
IR Controller Configuration
*WM:
*WM: Configuring access point...
*WM: IR Controller Configuration
*WM: AP IP address:
*WM: <IP_ADDRESS>
*WM: HTTP server started

Ive change the pins around a bit because there are less on the D1 Mini, and i soldered up a little pcb that way. The Config button isnt soldered to anything - cant get it to hand out wifi. Worked great on my larger NodeMCU Amica

Looks like its in access point mode and hosting WiFi as it should be
For whatever reason instead of hosting on <IP_ADDRESS> its hosting on <IP_ADDRESS> maybe that’s the issue? But its definitely in AP mode
From: sjp770
Sent: Monday, November 20, 2017 7:31 AM
To: mdhiggins/ESP8266-HTTP-IR-Blaster
Cc: Subscribed
Subject: [mdhiggins/ESP8266-HTTP-IR-Blaster] Using on a Wemos D1 Mini - wificonfig wont start (#79)
This is what I get when I try to start into config mode straight after flashing:
ESP8266 IR Controller
Config pin GPIO16 set to: 0
*WM: settings invalidated
*WM: THIS MAY CAUSE AP NOT TO START UP PROPERLY. YOU NEED TO COMMENT IT OUT AFTER ERASING THE DATA.
mounted file system
*WM: Adding parameter
*WM: hostname
*WM: Adding parameter
*WM: passcode
*WM: Adding parameter
*WM: port_str
*WM: Adding parameter
*WM: user_id
Using Static IP
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: <IP_ADDRESS>
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0
*WM: SET AP STA
Entered config mode
<IP_ADDRESS>
IR Controller Configuration
*WM:
*WM: Configuring access point...
*WM: IR Controller Configuration
*WM: AP IP address:
*WM: <IP_ADDRESS>
*WM: HTTP server started
Ive change the pins around a bit because there are less on the D1 Mini, and i soldered up a little pcb that way. The Config button isnt soldered to anything - cant get it to hand out wifi. Worked great on my larger NodeMCU Amica
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

But an ssid scan doesn't show anything. Due to the reduction in pins can I
remove the extra transmit pins?
On 21 Nov. 2017 01:13, "Michael Higgins"<EMAIL_ADDRESS>wrote:

Looks like its in access point mode and hosting WiFi as it should be
For whatever reason instead of hosting on <IP_ADDRESS> its hosting on
<IP_ADDRESS> maybe that’s the issue? But its definitely in AP mode
From: sjp770
Sent: Monday, November 20, 2017 7:31 AM
To: mdhiggins/ESP8266-HTTP-IR-Blaster
Cc: Subscribed
Subject: [mdhiggins/ESP8266-HTTP-IR-Blaster] Using on a Wemos D1 Mini -
wificonfig wont start (#79)
This is what I get when I try to start into config mode straight after
flashing:
ESP8266 IR Controller
Config pin GPIO16 set to: 0
*WM: settings invalidated
*WM: THIS MAY CAUSE AP NOT TO START UP PROPERLY. YOU NEED TO COMMENT IT
OUT AFTER ERASING THE DATA.
mounted file system
*WM: Adding parameter
*WM: hostname
*WM: Adding parameter
*WM: passcode
*WM: Adding parameter
*WM: port_str
*WM: Adding parameter
*WM: user_id
Using Static IP
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Custom STA IP/GW/Subnet
*WM: <IP_ADDRESS>
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0
*WM: SET AP STA
Entered config mode
<IP_ADDRESS>
IR Controller Configuration
*WM:
*WM: Configuring access point...
*WM: IR Controller Configuration
*WM: AP IP address:
*WM: <IP_ADDRESS>
*WM: HTTP server started
Ive change the pins around a bit because there are less on the D1 Mini,
and i soldered up a little pcb that way. The Config button isnt soldered to
anything - cant get it to hand out wifi. Worked great on my larger NodeMCU
Amica
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mdhiggins/ESP8266-HTTP-IR-Blaster/issues/79#issuecomment-345704722,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AY9myRJSpUvPqb5Y9okmX7fFOGUW8nowks5s4YcYgaJpZM4QkMNv
.

You can change the pins around to whatever you want and you can delete additional transmission pins as needed

Any updates? Gonna close this due to inactivity, feel free to reopen

Not solved. Wont enter config mode, when the config  pin is pulled low. Can I hard code the initial ssid and password?


Anchor links on mobile go to the wrong place

Here is a paper I wrote using bikeshed. If you load it on mobile and start clicking on the links (either the table of contents links or the self-links next to the sections), they don't... quite go to where they're supposed to. Some of them work sometimes, others target somewhere later than where they're supposed to go. For instance, clicking on 4.4.2 from the table of contents takes me nearly to 4.5.
There's something about the <meta name="viewport" > tag that causes these links to do weird things, but I am not familiar enough with any web technology to do offer more than that.

Woah, weird. This looks like a browser bug? It's just an anchor link, and the anchors are in the headings, right where you'd expect. If the navigation isn't scrolling to them, that's messed up on the browser side.
I can reproduce this in modern Android Chrome, but it doesn't reproduce in iOS browser. I'll report this on Chrome, thanks for the notice.
I'll go ahead and close this tho, as there's nothing Bikeshed can really do, I think.

(By the way, I recently pushed an update to Bikeshed's styling that should make large tables render better. Where's the source for your paper? I'd like to test that it works properly on your code-example blocks.)

Filed at https://bugs.chromium.org/p/chromium/issues/detail?id=971237

Thanks! Honestly, I'm glad it's a browser issue -- that seems saner than any kind of explanation where direct links to ids don't work...
The source for that paper is: https://github.com/BRevzin/cpp_proposals/blob/master/0847_deducing_this/deducing-this.bs


Delete item with delete key

When I select a todo item, and press the delete key, the item is not deleted.

This should be present in 1.3.0. Feel free to re-open, if there is an issue with it.


Create setup.py

@karpathy , Thank you so much for the implementation.
I have added setup.py to facilitate installation (using pip preferably).
Can we add this please?

I have tested it works for 3.10.
Didn't test yet for other versions.
If it works for other version, please do change the range of versions.


Roll forward global tools

Hi, thanks so much again for these fabulous tools! In case you don't remember, I use NetCoreBeauty v1 as part of my tool GameBundle.
Unfortunately, all of the global tools attached to this project don't have the RollForward directive, which means that users have to have the exact version of .NET installed that the tool was built with to use it. In most cases, this is unnecessary, as newer versions are usually backwards-compatible for tool execution.
I recently updated GameBundle to include this feature, but essentially all you have to do is add this to your project file:
<RollForward>Major</RollForward>

For more info, I used the official documentation from here: https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#rollforward
Thanks so much, and I hope you consider adding this directive to the v1 global tool as well!

--roll-forward option is added to both v1 and v2.

Thanks so much for adding this!
Unfortunately, I don't think you understood what my request was? I was asking for the NetBeauty global tools (specifically https://www.nuget.org/packages/nulastudio.ncbeauty and https://www.nuget.org/packages/nulastudio.nbeauty) to have the RollForward directive added to them, so that people using your tools don't have to have outdated versions of .NET installed.

oh, you mean the global tools ncbeauty and nbeauty themself?

Yes! Currently, to use them, you have to have .NET Core 2.1 installed. As I said in my original post, having the exact matching .NET version installed is almost never necessary for tool execution, so this is likely an unnecessary requirement.

the global tool has been updated, i tested it, it works very well, thanks for the advice.