CSHARP-975 fix: add check timestamp that cassandra gives if less then…

this is for https://datastax-oss.atlassian.net/browse/CSHARP-975.
i added the min value as long because DateTimeOffset.ToUnixTimeMilliseconds() is not available in .net=4.5.2

Hi, thanks for the issue report and the PR! It's still not clear to me what the best solution for this problem is so I'll keep investigating this.
I don't think the solution implemented in this PR is good enough because it basically modifies the data that is being read so the user will not actually be able to read the correct data from the database.
Since the type itself does not support the values that are being read from the database it seems to me that we have 2 options:

Introduce a breaking change and change the default C# type that is associated with this C* type
Introduce a custom serializer that users can use if they run into this issue (and potentially set this as the default in the next major version of the driver, whenever that happens)

i guess, the best way to fix it is fix the datetime lib in java :D
even if we fix it, it won't work old incorrect data.
we are using csharpdriver with json select, and then deserialize to entity object with external json lib(newtonsoft etc.).
therefore we prevented that DateTimeSerialization throws exception by not using.
maybe, new serializer that handle this issue would be good.
if i have a time, i am gonna look at what i can do better on this problem than this.


Outline Windows Client 1.3.3 stops working on Windows 10

Outline client version 1.3.3 works fine after installing in Windows 10. However after using for some time the client doesn't connect anymore.
This connection error can be solved by uninstalling Outline client and also uninstalling the 'TAP-Windows adapter' from Windows device manager with the option 'Delete driver software'. After reboot and reinstall Outline client is connecting correctly.
Desktop

Windows 10
Version Pro 20161.1000

Outline client

Version 1.3.3

Hi JackGraus, How are you?
Could you tell me,please how did you configure Cygwin, Node.js and Yarn to connect Outline Client on Windows OS.
I will be greateful If you guide me step by step

Hello, I am using the Windows 10 outline client 1.3.3 build as delivered in Github. Not using Cygwin.

Ok...thanks a lot...mine is windows 8.1 and doesn't connect on
Outline-client 1.3.3
I will try on Windows 10
On Thu, 23 Jul 2020, 09:58 JackGraus<EMAIL_ADDRESS>wrote:

Hello, I am using the Windows 10 outline client 1.3.3 build as delivered
in Github. Not using Cygwin.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Jigsaw-Code/outline-client/issues/815#issuecomment-662818526,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQGD6OTNY2TQXVOKPEZCKELR467N7ANCNFSM4OOV7TCQ
.

This works for me now for client 1.3.3. But also for later versions after deleting all Hyper-V adapters from Windows device manager. Also the hidden Hyper-V devices and the ones in System devices. And after disabling Hyper-V services.


README outdated WRT java 14 and 15

Both Java 14 and 15 are already released, they are not ea any more.

While we can and probably should update the README regularly to include the latest available versions (e.g. add 14 and 15 to the list of non-EA versions in the examples, and 16-ea to the EA versions), the language for the README should aim to remain correct even if we don't update it every 6 months. The version numbers in the README are examples of how to use the version specification syntax and not necessarily an exhaustive list of what is available at a given point in time.
We don't need to necessarily remove all older EA version specification examples each time when the non-EA version comes out (this will happen every 6 months). The EA version specifications for 14 and 15 still work, as stated, and will continue to work. It's just that there are also non-EA versions of the same.

Hello everyone. We released setup-java@v2 and updated documentation according to it. You can see supported versions for each distribution through their official sites.


Avoid unnecessary network requests for 404 handles

While retrieving submissions - blacklist the handles that return 404 to optimize future retrieval.

Need to change the code significantly since the get_request function is unaware of the user record and the calling function is unaware of 404.
Possible approach:

Keep a table to store the handles and the site and then do not make the request if the handle exists in this table
Just make one db query to this table when submission function is called and maintain a set to store the handles which result in 404s.

Edge case that is not considered:
User entered some random handle (which gives 404 on Codechef say) and now he registers on CodeChef with this handle.
Solution:
One more cron script needs to added so that it can check if the handles are still giving 404 or not.
If it does not then remove the entry from the table.
Next:
How to get the submissions from this newly registered handle :p - f***ed :smile:
Now this needs #91 to be solved first!


Simplify constraining a repository enumeration for a single graph

RDF::Graph uses RDF::Repository for it's data model, and does not support the notion of a context separate from that within the repository it comes from. In some cases, it's useful to create a context for a repository restricted to just a single graph. Right now, this might be done using the following:
repo.enum_graph.detect {|g| g.context == graph_name}

Operations such as Enumerable#graph(graph_name) and Enumerable#with(graph_name, &block) can simplify working with a single graph.

The idea being that the block takes an object that's also an RDF::Enumerable (or superset thereof), but restricts all quad operations performed on it to be scoped to the given graph only?

Effectively. I think RDF::Enumerable#with(graph_name) yields those constrained quads if given a block, and returns an #enum_for otherwise, which then is pretty much the same as an RDF::Graph.

I added this with basic support in Enumerable, and simply creating the appropriate Graph in Repository and Graph.
@no-reply @bendiken This needs to be merged soon, as the rdf-spec 3.0 branch has the tests in already, but I wanted to leave it briefly from a review. If I don't hear anything from you tomorrow, I'll go ahead and merge in.

This seems good. Presumably we'll want to implement repositories to optimize the with request. I suspect this will make things nicer for RDF::LDP...
Not sure about the clarity of #with as a method name, but I don't see that as a blocker, unless we have a better idea immediately.

I'm open to alternates; constrain? project? extract? graph?

Renamed to #project_graph in a69cb02c3357f220886f94ee244e26ed3d3bad3d.

that's not necessarily a requirement for 2.0
[2:35pm] tjohnson: * tjohnson: how does this interact with changesets?
[2:37pm] tjohnson: * bendiken: we should merge in the latest upgrades to transaction and tjohnson can look at how things look

@no-reply to verify with Blazegraph.

This looks good with existing work on transactions. :+1:


Add batch.v1beta1 for cronjob

Just curious: what's our use case?

@andrepoleza https://nubank.slack.com/archives/CAHT5P6U8/p1569278009046900


Add UI

[x] add icons to the buttons
[x] move logic from controller to a service
[x] refactor with "each db connection"
[x] intro new env var for "disabled"

Manual testing results:

down migration cannot be rolled back, so hide the button?

If no phantom migrations the table looks clunky

Show some text saying no phantom migrations instead of the empty table?

3. WDYT if we don't show down phantom migrations in the table at all? Reason - there is no point in running it up and also since it's down the user cannot do with it anything. This kind of migration is useless for the current branch too. So if it's hidden the user won't notice. It's not a relevant thing that can be destroyed. I tend to think we can remove it entirely on down. Please tell what do you think, thanks!

I think this is a great idea


Switch to singlepp's new intersection builders

This avoids having to encode nulls as incomparable, because we can just pass in the intersection from Javascript-land.

Closed by #90.


Which qpkg variant to download?

Looking at the current release, there are the following variants:

Tailscale_1.36.1-1_arm-x19.qpkg
Tailscale_1.36.1-1_arm-x31.qpkg
Tailscale_1.36.1-1_arm-x41.qpkg
Tailscale_1.36.1-1_arm_64.qpkg
Tailscale_1.36.1-1_x86.qpkg
Tailscale_1.36.1-1_x86_64.qpkg
Tailscale_1.36.1-1_x86_ce53xx.qpkg

I have a QNAP TS251+, which has  Celeron processor that supports 64bit, so I'm guessing I need the Tailscale_1.36.1-1_x86_64.qpkg variant... Is there a list somewhere that tells me which version is best suited for which QNAP device?
Edit: I had to manually upgrade from firmware 4.5 to 5.0 to make it work. Proposal: I think it would help to mention this requirement in the README

Hi,
I'm guessing the same : for a QNAP TS251+ NAS, with an Intel® Celeron® Processor J1900 inside, the Tailscale_1.36.1-1_x86_64.qpkg variant seems to be the best.
As far as I know, no list is available online to associate a NAS (or a processor) to the best variant. We still have to check the manufacturer processor specs (especially the Instruction Set Architecture) to determine the right variant.

Just choose the one for your CPU architecture. x86_64 is what you want if your CPU supports 64-bit.


added cldfreadme, missing ref, genealogy sources

Would be good to also adapt this: https://github.com/cldf-datasets/wals/blob/master/RELEASING.md


ValueError ----> 1 cnn.fit(X_train, y_train, epochs=2)

Code:
cnn.fit(X_train, y_train, epochs=2)
I got an error:
ValueError Traceback (most recent call last)
in ()
----> 1 cnn.fit(X_train, y_train, epochs=2)
My Code Link in colab:
https://colab.research.google.com/drive/1dy-q0E8B7siaWNRhG9CVNWuw1NBIOTl2?usp=sharing
Total Code:
import tensorflow as tf
from tensorflow.keras import datasets, layers, models
import matplotlib.pyplot as plt
import numpy as np
(X_train, y_train), (X_test,y_test) = datasets.mnist.load_data()
X_train.shape
X_test.shape
plt.figure(figsize=(15,2))
plt.imshow(X_train[0])
y_train[:10]
y_train = y_train.reshape(-1,)
y_train[:10]
classes = ["five","zero","four","one","nine","two","one","three","one","four"]
def plot_sample(X, y, index):
plt.figure(figsize = (15,3))
plt.imshow(X[index])
plt.xlabel(classes[y[index]])
X_train = X_train / 255.0
X_test = X_test / 255.0
cnn = models.Sequential([
layers.Conv2D(filters=28, kernel_size=(3, 3), activation='relu',
input_shape=(28, 28, 3)),
layers.MaxPooling2D((2, 2)),
layers.Conv2D(filters=56, kernel_size=(3, 3), activation='relu'),
layers.MaxPooling2D((2, 2)),
layers.Flatten(),
layers.Dense(28, activation='relu'),
layers.Dense(10, activation='softmax')
])
cnn.compile(optimizer='adam',
loss='sparse_categorical_crossentropy',
metrics=['accuracy'])
############ Error in below code############
cnn.fit(X_train, y_train, epochs=2)

Hi @shajibul!I have fixed above issue by changing input_shape = (28,28,1) and reshaping the train,test data from Mnist dataset. Attaching Gist for reference.

Yes, Thanks a lot


Ingest generated spreadsheet processes do not link to multiple dissociation protocols

Describe the bug
Dissociation and enrichment protocols (and possibly others) are not linked appropriately in the Ingest-generated-xls spreadsheet for a project
To Reproduce
Steps to reproduce the behaviour:

Go to 'https://contribute.data.humancellatlas.org/submissions/detail?uuid=87da3563-99af-4e55-9c30-2732b0af07d4&project=77c13c40-a598-4036-807f-be09209ec2dd'
Click on 'Download xls spreadsheet'
In the spreadsheet, go to the 'cell_suspension' tab and find process with uuid 59e90e1e-0098-43e3-8297-c6563d287f1d
The process should be linked to only one dissociation protocol.
In Ingest UI, scroll down to 'Processes'
Find process with uuid 59e90e1e-0098-43e3-8297-c6563d287f1d - it should be linked to multiple dissociation protocols

Expected behaviour
The generated excel spreadsheet should have processes which are linked to multiple dissociation protocols, as shown in Ingest UI
Screenshots / Logs

If applicable, add screenshots or log files to help explain your problem.

Links

If applicable, link to relevant docs or Slack conversations.

Environment

[x] prod
[ ] staging
[ ] dev

Browser

[x] Chrome
[ ] Safari
[ ] IE
[ ] Other (please specify)

Found the error, the problem is in this line:
https://github.com/ebi-ait/ingest-client/blob/master/hca_ingest/downloader/flattener.py#L156
tl;dr: When multiple protocols of the same concrete type (e.g. dissociation_protocols) are present in linkings, alongside other types (e.g. enrichment protocols), the function tries to group them based on that concrete type. However, the groupBy function only works on ordered lists. In the example above, the protocol list for all processes going into cell suspensions has the following order:

Dissociation protocol
Enrichment protocol
Dissociation protocol
Which ends up deleting the first dissociation protocol when iterating.

I have written a bit of a snippet on a solution, but not sure if it's the best one:
def sort_by_concrete_type(prot):
    return prot.schema.concrete_type
for concrete_type, inputs_iter in groupby(sorted(entity_of_interest.protocols, key=sort_by_concrete_type), lambda entity: entity.schema.concrete_type):

@ESapenaVentura to open a PR for review by @amnonkhen

PR to fix this: https://github.com/ebi-ait/ingest-client/pull/69

hey @ESapenaVentura and @amnonkhen  - is this now resolved, should it be closed?

Hi @gabsie - No, the PR has not yet been merged. I will merge on Tuesday and check how to push the new version to the broker and exporter

Waiting on access to pipy - Will deploy version 2.8.1, then merge PR, then create PRs in the Ingest graph validator, Ingest broker and Ingest exporter repositories to update the dependency


Potential issue in the calculation of dF/F

According to the sample notebook at https://github.com/ThomasAkam/photometry_preprocessing/blob/master/Photometry data preprocessing.ipynb
In the dF/F calculation, the denominator should be the low-pass filter signal, not the photobleached correct signal. But in
https://github.com/juliencarponcy/trialexp/blob/b5765531083a9c17be9e1fcbc56a171b1826f4a9/trialexp/process/pyphotometry/utils.py#L170-L191
the filtered signal actually is the low-passed and high-passed signal. The high-passed signal will have a baseline very close to zero, which will lead to problem when calculating analog_1_baseline_fluo and subsequently dF/F

Fixed in :
https://github.com/juliencarponcy/trialexp/pull/9/commits/2bd4307af9ce2096ff1673b56cf6bacf0a2a8127#diff-90aedd18a2a5cd46987018614831622fb110ef9b08b1d3baad395bf36c0a6e1c
The parameter named high_pass was renamed to baseline_low_pass to avoid confusion:
Indeed baseline substraction involve doing a very low LOW-PASS filtering (0.001 as per Thomas Akam examples) instead of a high-pass at 0.001.
Fix implemented in current Experiment workflow (data_import.py), switched to (semi) functional method in
https://github.com/juliencarponcy/trialexp/commit/e1d585a4bcc4137084603a14fa555ba6f7d830f3


Restructuring the 'References' section

This PR includes the following changes for the References section:

Renamed the following ids and file names:

cli -> okteto-cli
manifest -> okteto-manifest
compose -> docker-compose

Added redirects
Updated links for these new names

cc @huguestennier for redirect review (should be quick/simple 🙏 )
cc @jmacelroy for overall review


Feat/auth

Implement user authorization

add endpoint
add schema
add model
add test

refactor user endpoint, get user info from JWT token

Just temporary force convert ACCESS_TOKEN_EXPIRE_MINUTES to int, will reactor whole Config class in #6


I wish /docs/getting-started-guides/docker/ existed

I wish /docs/getting-started-guides/docker/ existed since its referred by https://github.com/kubernetes/kubernetes/tree/master/cluster/images/hyperkube :)

Link updated.


Mac OS, can't hide the "top-system bar" anymore in borderless full screen

If I create a borderless full screen window, the persistent "menu bar / top bar" (don't know its official name) stays on top, and actually pushes the window down with its height, making things render outside of the bottom of the screen.
I've tried the decorated flag. I've also tried editing the Info.plist
LSUIPresentationMode
3
Now this edit actually worked in an older version of GLFW, but when I upgraded, the issue is back.
Any ideas?

Which commit introduced the issue? Which OS version? Which computer? Does the computer have a notch at the top (MBs)?


proposal: encoding/baseXX: add Encoding.RejectLineFeeds

Currently, base32 and base64 ignore carriage returns and linefeeds by default.
This behavior goes against RFC 4648, sections 3.3 which state:

Implementations MUST reject the encoded data if it
contains characters outside the base alphabet when interpreting base-encoded data,
unless the specification referring to this document explicitly states otherwise.
Such specifications may instead state, as MIME does, that
characters outside the base encoding alphabet should
simply be ignored when interpreting data ("be liberal in what you accept").
Note that this means that any adjacent carriage return/line feed (CRLF) characters
constitute "non-alphabet characters" and are ignored.

Rejection of "characters outside the base encoding alphabet" (including carriage returns and line feeds) should be the default,
unless specified otherwise by some higher-level specification (e.g., MIME).
The decision to allow \r or \n should not have been made by the base32 and base64 packages,
but rather by the users of it.
Today, base32 and base64 already ignore \r and \n by default and we can't change that,
but we should expose control over this behavior:
// RejectLineFeedscreates a new encoding identical to enc except that
// rejects the presence of carriage returns and line feeds as
// described in RFC 4648, sections 3.1 and 3.3.
func (enc Encoding) RejectLineFeeds() *Encoding

An alternative and more flexible API is (per https://github.com/golang/go/issues/54054#issuecomment-1194998778):
// WithIgnored specifies a set of non-alphabet characters that are ignored
// when parsing the input. A newly created Encoder ignores '\r' and '\n' by default.
func (enc Encoding) WithIgnored(chars string) *Encoding

My original proposal would be equivalent to enc.WithIgnored(""),
while #54054 could be accomplished using enc.WithIgnored("\t\v\f \r\n").

This feature combined with #53844 makes it possible to implement a truly bijective mapping between baseXX and binary data. This would allow the use of base32 and base64 to produce a truly canonical encoding per RFC 4648, section 3.5.

golang/protobuf#1626 arose because the "google.golang.org/protobuf/encoding/protojson" package implicitly allowed newlines and carriage returns because the default behavior of the "base64" package is to ignore such characters. Having this option to begin with would have avoided that problem.

I like the idea of WithIgnored as all sorts of whitespaces are common when dealing with various base64 uses. This option also gives the greatest flexibility to allow for strict nothing else but valid characters, the current newline/carriage return only ignored, and more flexible permissive whitespace ignoring in general.


Intermittent Travis build failures

It always seems to be the same test failing:
1) CacheTest::testCacheLifetime
Failed asserting that false matches expected 'Good'.

Perhaps we should increase the lifetime set in that test slightly and see if it ever crops up again

These failures don’t seem to happen anymore


[documentation] Iroha-SDK release interdependency

Documentation URL(s)
https://github.com/hyperledger/iroha/blob/iroha2-dev/docs/source/release_procedure.org

Let's create a table that outlines the SDK update process and its relationship to Iroha releases something like below. This would enhance transparency and clarify tasks and responsibilities at each stage.
Just for example:

Stage
Who Does It
What To Do

1
Project Manager
Conduct a pre-release sync meeting.

2
Tech Lead
Appraise all present of main API-breaking changes requiring attention.

3
Tech Lead
Walk through the differential between iroha2-stable and iroha2-dev branches.

4
Core Team & SDK Teams
Sign off on a release and announce the opening of the release window.

5
DevOps
Release a nightly docker container through the continuous delivery system.

6
Tech Lead
Create a Pull Request from iroha2-dev to iroha2-stable with the release checklist.

7
SDK Engineers
Allocate resources for SDK updating.

8
SDK Engineers
Update SDKs (Kotlin/Java, JS/TS, Python, Swift) for compatibility with upcoming Iroha release.

9
Project Manager
Confirm that SDKs are updated and functioning; otherwise, move to an internal release.

10
QA Engineers
Update Iroha-related tools like iroha-squash for new SDK versions.

11
Core Team Developer
Review and tick off points on the release checklist related to SDK updates.

12
Core Team Developer
Report any major breakages in the relevant chat and respond to inquiries about changes.

13
Core Team Developer
Produce standard packages (Nix, AppImage, .deb, .rpm) and upload to relevant locations.

14
Project Manager
Form a proper GitHub release and provide links in relevant chat.

15
Tech Lead
Close the release window upon completing the release checklist.

@dmitrivenger should we close that?

closing in favor of https://github.com/hyperledger/iroha-rfcs/pull/10


Add Grove Range Request handling

Currently, Range headers are ignored. (Though dropping range headers via a plugin is trivial.)
Grove should respect Range requests, ideally:

make Range requests upstream to the parent/origin
store only the received range, indicating the range of the stored bytes in the CacheObj
merge successive ranges for the same object
when a request comes in for the entire object, request only the un-held bytes (considering whether held bytes are Fresh, response Last-Modified, etc)
only loading the requested bytes from the cache (this probably doesn't matter for memory, but does for disk, especially for massive objects requested via successive small range requests [for example, by storing objects in the cache in chunks])

This ideal doesn't have to be implemented all at once. For example, a first step would be returning the requested range; but requesting, storing, loading, etc the full object as normal.
See https://tools.ietf.org/html/rfc7233

Is #2262 truly only a partial fix for this? It seems like it might implement it in totality.

I'm not sure, it'd take some time to look over the code in depth. But I think it only implements it to the client, not the upstream parts.

converts the upstream request to a "normal" (no range) request, and stores the 200 response

So it's not doing things like:

when a request comes in for the entire object, request only the un-held bytes

merge successive ranges for the same object

I think it replicates range requests to the upstream in the second mode. That doesn't mean it does those two things, though.


scp/sftp functionality

it would be nice, if files could be shared via scp/sftp

I second this. VX ConnectBot Code for it is here: https://github.com/vx/connectbot/blob/master/src/com/trilead/ssh2/SCPClient.java

Third. This would be amazing.

Two years after, I'm allowing myself to bump this. VX ConnectBot seems dead, the last commit is from Oct 30, 2013. But the SCP code is still in there. :)

I would love this feature.
Any open source solution to scp?

+1

Ping pong bump

Any update?

+1


Single page enumeration - restart enumeration for every page?

I want to have my single pages enumerated, ie. every page should have the enumeration starting at 1.
So I googled and tried ignorantshr/mkdocs-add-number-plugin first, but noticed that it does not work when using things like  {% include 'template.md' %} - headers that are included from files are not enumerated correctly. The headers are printed correctly, but are ignored in the enumeration.
Then I noticed that your plugin is a rewrite and gave it a try and it worked like a charm even when using include statements. Thank you very much for your work!
However, as I understood your plugin focuses on the enumeration of all the content on the page and from what I have read does not provide the possibility that the enumeration "re-starts" for every page.
Can you please confirm or deny if your plugin can be used to also have single pages enumerated?

It's not currently supported, but it's very easy to implement.
I'll try to release a new version somewhere this weekend.

Btw, I am curious, what's your use-case for this feature?
I don't use this plugin anymore (I use mkdocs-print-site-plugin), but maybe there are use cases I've missed.

I'll try to release a new version somewhere this weekend.

That would be great and I would really appreciate it.

Btw, I am curious, what's your use-case for this feature?

I am trying to slowly move documentation that existed as separate PDF documents to an online version using mkdocs.
Each document is in a separate sub-directory and is nicely rendered using mkdocs, however I'd like to have it enumerated to make look a little more like an ordinary PDF document. Also having it enumerated makes it easier to distinguish the different levels of "indentations" more easily, because you don't have to rely on the different visual representation of the headings.

Ah that makes sense!
New version released: https://github.com/timvink/mkdocs-enumerate-headings-plugin/releases/tag/v0.5

New version released: https://github.com/timvink/mkdocs-enumerate-headings-plugin/releases/tag/v0.5

Thank you very much for the new release. I can confirm that it works as described.
Adding the "increment_across_pages: false" option makes the enumeration re-start with every page.


[WIP] Removal of Sentry SDK

Testing deployment with Sentry SDK removed

Workshop netlify functions appear to have an issue now that the Sentry wrapper has been removed. The is error returning is {"error":"invalid_client","error_description":"Wrong redirect uri was provided."}


Reduce debug logging to something more manageable for normal setups

Describe the bug
Debug Log is filled with thousands of messages generated by NPC tokens.
Illandril's Third Pact Slot | Actor[Commoner] is not a character
What steps did you take before experiencing the problem?
Steps to reproduce the behavior:

Load foundry scene.
Select any token
Watch as debug log fills to infinity.

Screenshots

Foundry Versions

Version of this module: 1.2.5
Foundry Version: 9:225
System Name and Version: DnD5e - Fifth Edition System, version 1.5.7
Browser Name and Version: Edge Chromium (Latest), Firefox (Latest)

Occurs even when only running only this module (Find the Culprit step one)

Those log messages are there for a reason, and they're not infinite (the more actors you have, the more messages you will get).
I will consider adjusting these messages to be a little less verbose in the future by default, with a way to turn just these specific messages on in the future when needed... but probably not any time soon. These messages only appear in the browser console and are already at the debug level, making them extremely easy to filter out.
If you don't want the verbose debug messages in general (which you should almost never need to see), you can turn off "Verbose" logging in Chrome and Edge (it is off by default for Chrome and Edge at least, so you've done something to turn it on for Edge), and Debug logging in Firefox.
Instructions for adjusting the filter for Edge (the same instructions work for Chrome; Firefox is very similar): https://docs.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/console/console-filters
If you want debug logging, but just want to filter out these specific messages, you can type -illandril into the filter to exclude all messages from any of my modules (or -"Deriving pact slots" -"] is not a character" to more narrowly focus the filter to just exclude these two specific messages).

Unfortunately in my situation, it is infinite, it loops across all actors on the scene, 6k messages in a few minutes.
Also, hiding the debug does not negate the fact that its looping in the background and causing actual performance issues.

If you make a script macro, with the command alert(game.actors.size);, and execute it, what number do you see?

Actually, run this macro instead, to also include tokens:
let min = 999999;
let max = 0;
let total = 0;
game.scenes.forEach(s => {
 const t = s.data.tokens.size;
 min = Math.min(min, t);
 max = Math.max(max, t);
 total += t;
});
alert(`Actors: ${game.actors.size}, Tokens Min: ${min}, Max: ${max}, Total: ${total}`);


NoSuchAtributeNamesError when where true = true

TutorialD (master/main): :showexpr true where true = true
ERR: NoSuchAttributeNamesError (fromList ["true"])
TutorialD (master/main): :showexpr true where true /= true
┌┐
││
└┘
TutorialD (master/main): :showexpr true where relation{tuple{}} = true
┌┐
││
├┤
└┘
TutorialD (master/main): :showexpr true where true = relation{tuple{}}
ERR: NoSuchAttributeNamesError (fromList ["true"])
TutorialD (master/main):

Oops, I just wrongly thought left side of equal could be anything.

Actually, I think that this is worth discussing. The current implementation assumes that the each left side of the equality is an attribute, but I think it's fair to request that:
x where @y=3;
x where 3=@y;

should be the same query. The problem in the current code is due to the desire to keep the grammar context free. In the query:
x where y=z

x is unambiguously an relvar but y and z could be relvars. If y is a relvar and z is an attribute, then z must be a relation-valued attribute. In order to keep the grammar context-free so that the backend doesn't have to guess (sometimes incorrectly) whether the attribute or the relvar is intended, we have adopted the @attribute syntax where needed to disambiguate. This could be done here as well:
x where @y=@z

unambiguously refers to y and z as attributes. (This syntax is not currently supported.) However, this means that referring to attributes in the where filter will always require the "@" sign. It seems like a sweeping change, but perhaps it is worth it to keep the syntax unambiguous. What do you think? Would you mind using the at-sign wherever an attribute is used? Is there a better alternative?

Good question... do we really need an relvar on the left side? (I was trying that if x where true = true leaves x untouched.) I can't think of a useful case.
Right now, we don't need to use @ on the left side of =, and when I use where operator, I feel like I am querying something. So attribute name only on the left side seems right.
And I don't mind use @ in right side of = in where and := in extend. It reminds me it is a calculation by row/tuple. Now, I don't feel right if it is omitted on the right side of = and :=.
So the design right now feels right to me.
But If we want to omit @ at all ... How about this?
Where and extend always brings variable names (attribute names) into scope. We make a rule that attribute name is always over relvar name (if you want to use some relvar, just use alias to rename it.)
then names will always refer to the nearest value in nested where and extend.
I sometimes want to use @attr where ... but failed.
But I have managed to find a way to bypass the need.


[RFC] Introducing Dependency Injection

What kind of business use case are you trying to solve? What are your requirements?
Dependency Injection(DI) is the technique which objects receive their dependencies. Leveraging this technique and moving instantiation of dependencies out-side of the scope of an object give us a the following benefits:

Objects align with the Single Responsibility Principle when they are not responsible for creating their dependencies
Coupling this technique with interfaces allows an object to support Dependency Inversion and easily swap implementation of dependencies without impacting the object’s implementation.
Easier unit test mocking. Dependencies can be mocked and injected.

What is the problem? What is preventing you from meeting the requirements?
Data Prepper (DP) does not utilize any Dependency Injection(DI) frameworks at this moment nor are we leveraging an existing framework which supports DI. Without a DI framework there are numerous code smells in DP. Currently, DP couples construction of dependent objects with implementation of other objects. DP also has cyclical dependencies and leverages static methods and instances to solve its own singleton management.
Other Requirements

Solution should be extendable to plugin framework and support runtime integration for DP plugins.
Supports new Directory Structure Proposal and proposed plugin architecture

What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
We will adopt dependency injection framework to eliminate the current code smells in DP and help drive DP towards a more modular architecture.
What are remaining open questions?

What DI framework should we adopt? There are three well known frameworks: Spring, Guice, Dagger.

All three frameworks should work for our use case. While dagger is a compile time framework it does support assisted injection for runtime creation.

Overall, I'd like to see the following available:

Data Prepper Core classes will have beans/instances available for dependency injection which are only part of Data Prepper Core. This likely would be the initial solution.
Plugin authors can create their own sets of beans/instances to inject for their plugins so that they get the benefits for a DI framework.
Both Core and Plugin can have a shared set of beans/instances which are available for use. This may not be necessary, but I'd like to be able to have it as an option.
It also might be interesting for the plugin framework to add beans/instances to the Plugin set, rather than pass them in directly.

Spring DI has robust support for these needs. It generates application contexts at runtime (which is good for plugins). It supports application context inheritance which would work well for having a Common context which can be shared (item 3 above). And we can programmatically add beans which can help with item 4.

Dagger won't be able to support core dependencies injected into plugins while Guice and Spring can. Given Spring's robust support, let's move forward with it. All plugin frameworks support JSR-330 and we should be able to easily migrate to one over the other if we identify issues (i.e start up performance impact).


need non-global way to do delete connect.bodyParser.parse['foo']

In a vhost situation changing the global connect causes unexpected behavior:
delete connect.bodyParser.parse['foo']

I would expect the way to do this to be something like:
var bodyParser = connect.bodyParser()
  ;

delete bodyParser.parse['foo'];

Or to be able to pass in options that override the defaults
connect.bodyParser({ parser: {'foo': null } })

agreed. we need to localize all of the middleware in a similar fashion. We can still write exports.parse['whatever'] but do var parser = options.parser || exports.parse['json blah blah'].


New example for a remote procedure call (RPC) with a hook based timeout

Here's a new example to timeout the loop in case you only want to wait for a certain amount of time for an ACK. I tried to keep your style as much as possible.
Based on this issue.
Let me know if there are any problems

Thank you for the PR! 🎉
I moved the example to another directory, added it to the README and reworked the code style a bit. Hope this is ok for you!

Sure it is, I really hoped you would actually


crashes on surf export as PDF - Win10 Matlab2017a

Hi altmany, love the script. I have been using it for a while. I got in trouble recently trying to get a SURF plot to be exported, Matlab just gets busy and crashes finally. If I try to do the same on a similar plain PLOT (same data overlayed) no trouble at all.
Don´t know if this is coming because of the type of plot or if it is coming from a missing extra parameter I should be using.
Op. System: Win 10 x64
Matlab: 2017a

Post the complete set of Matlab commands that you are using and I will try to reproduce the problem. Perhaps it's a problem with the combination of plot and export_fig commands that you are using so without the complete commands I cannot reproduce.

No feedback received in 4 years, so closing this issue


Clear text styles

Describe the requested icon
An icon that for an button that removes styling from text. This is useful for e.g. rich text editors.
Screenshots

Additional context

This request is related to #246.
There is no standard for this kind of icon, but it seems like the example in my screenshot is the most popular one (see google search results)
I attached my own version of this icon which is based on text-t

We're going to go ahead with text-t-slash as requested in #277, hope this works.


Flow schedule disable, enable function

Hi,
We have almost 200 batches , during maintenance we have to disable some based on the requirement and enable it after the maintenance.Right now, i could not see this feature in Azkaban. is there any workaround?.
Best regards

Disable/Enable button before "Execute Flow" would be good.

"Disable/Enable" button next to "Remove Schedule" would be better.
Currently we don't find any disable feature for the flows which are already scheduled. Please

If this function is already available, please guide us how to use it ?
Or is it planned for upcoming releases ?. We feel this is a very important feature missing. Where tools like rundeck has this one already.

We met same problem, it is really an important feature. Any updates on this? Or is it on the road map releases?

We haven't got any update yet from the community.
On Thu, 3 May 2018, 6:04 PM duke<EMAIL_ADDRESS>wrote:

We met same problem, it is really an important feature. Any updates on
this? Or is it on the road map releases?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/azkaban/azkaban/issues/901#issuecomment-386247163,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYceltnKI4sYBQO8EBdPtodobaTGMKYXks5tutY0gaJpZM4L6TOo
.

I can't speak for the repo owners, but usually they have welcomed pull requests to add generally useful feature (this seems like one).
However I would recommend you to do what we do and keep your schedules in version control outside of Azkaban and deploy them from there. That way you can easily create a script to delete schedules & add them back.


Switch to more standard config file location

Instead of home directory dot file for the rc file, would suggest conforming to XDG  standard, ie using $XDG_CONFIG_HOME (~/.config) and a folder within that, ie:
$XDG_CONFIG_HOME/gcalcli/config
which will usually resolve to $HOME/.config/gcalcli/config

The .gcalcli_cache and .gcalcli_oauth could probably go to ${XDG_CACHE_HOME}/gcalcli/{cache,oauth}, also.
Note: ${XDG_CACHE_HOME} usually defaults to ${HOME}/.cache

Looks like a good idea. The xdg-base-dirs package supplies these paths in a way that meets the standard.


[typescript] TransitionHandlers (onExited) are now NOT available as props for Dialog

since beta 26 (it was ok in beta 25) onExited and other TransitionHandlers are now not recognized as a proper property of Dialog when using typescript

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

onExited and other TransitionHandler properties should be available
Current Behavior

There's an error when using any of those properties with a Dialog
Your Environment

Tech
Version

Material-UI
26 beta

React
16

browser
latest chrome

ts
2.6.2

I confirm it's because the transition handlers have been removed from the Modal API. Maybe we should add it back so the Modal API is consistent with the other components.

What was the rationale for their removal?

@pelotom The rationale was about removing an indirection. With the new Modal API, people can provide a transition child component. So, they can apply the transition callbacks on the source.
On the other hand, the more abstracted components like the Dialog, Drawer or Snackbar take a transition property and proxy the transition callbacks.


(WIP) Fix dataframe.io API docs

Added some functions to the list.
One problem is all kwds in pd.read_csv are listed as "not supported" because dd.read_csv uses kwargs to handle them at once. I think there are some unsupported kwds like skiprows and skipfooter at a glance.
Considering a easy way to apply it to the doc.

We could also stop using **kwargs and explicitly write out all of the keyword names explicitly.  This would make some of the code a bit more verbose but would make us more explicit about what keywords we do and do not support.

What is the status on this?

I agree we should use all defined keywords explicitly. I'm going to distinguish non-supported kwds, hopefully finish this weekend.

Worked on this, and found this needs some logic change and tests because now all kwds are passed as default value. Pls give me a while.

This seems to be stale.  Closing for now.  Please reopen if this starts up again.