Metadata on deftest (and def)

Hi @kkinnear,
As our use of zprint increases, we are slowly tackling and opening issues when we don't know how manage some of our forms (as you saw :smile:)
Thank you in advance for your work, we are going to try 1.2.2 soon here.
In the meantime, we have many places where we declare metadata on stuff:
(def ^{:doc "Json serde. This enables our default camel-case out kebab case in behaviour."}
     default-json-serde
  serde/json-camel-kebab-serde)

(deftest ^{:database true ::test.hooks/system-init-keys system-keys}
         websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")]
    foo))

The meta seems to break the arg1-body setup and I am not sure how to handle that. I could probably go :inner but I thought I should ask first.

Hello @arichiardi.  Truly, thanks for asking.  I sat down to try to figure out a fix for this problem, but ... I can't quite figure out the problem.  When I try the two examples you gave, above, I get what you show (as long as my width is enough for the string in the first example).  Presumably you would like these two examples to look different than they came out?  Maybe it is obvious that there is a better way to format these and I'm just missing something? Perhaps you could give me your preferred output and I'll see what I can come up with to make that happen.  Thanks!

Oh dear, sorry I did not specify what the desiderata is:
(def ^{:doc "Json serde. This enables our default camel-case out kebab case in behaviour."}
  default-json-serde
  serde/json-camel-kebab-serde)

and
(deftest ^{:database true ::test.hooks/system-init-keys system-keys}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")]
    foo))

The funny thing is that some of the defs are actually behaving that way already, for example this one:
(def
  ^{:doc
    "Keys necessary for starting the application bus and the reactions.

Note that reactions will consume bus events so you won't be able to consume :chan directly."}
  ws-component-keys
  (into event-bus-component-keys
        [:appserver.lib.ws/endpoints ;; websocket config component (fed to pedestal)
         :appserver.lib.pubsub.components/pubsub ;; reaction component
         :appserver.lib.transport.components/transport-processor ;; websocket message processing
         :appserver.users/default-user :appserver.auth/params :appserver.uri.ws/scheme
         :appserver.uri/authority :appserver.uri.ws/path]))

First, let me say that this one is a real challenge.  It turns out that metadata is parsed together with the thing to which the metadata is associated and they show up as a single element.  So the usual ways I have of dealing with this don't really apply, since the metadata isn't two things when it is output from the parser (though it of course certainly looks like it is).  So my usual "here is a hack in the options map to get you what you want" is not on the table.
That said, I might be able to get you close to what you want.  Above, you said "some of the defs are actually behaving that way already, for example this one:"
(def
  ^{:doc
    "Keys necessary for starting the application bus and the reactions.

Note that reactions will consume bus events so you won't be able to consume :chan directly."}
  ws-component-keys
  (into event-bus-component-keys
        [:appserver.lib.ws/endpoints ;; websocket config component (fed to pedestal)
         :appserver.lib.pubsub.components/pubsub ;; reaction component
         :appserver.lib.transport.components/transport-processor ;; websocket message processing
         :appserver.users/default-user :appserver.auth/params :appserver.uri.ws/scheme
         :appserver.uri/authority :appserver.uri.ws/path]))

Except that one isn't, to my eyes anyway, actually behaving like you said you wanted it.
My understanding of what you want from your first two examples is to have the metadata on the same line as the def or deftest, and the symbol on the next line.  Also, the symbol is not lined up in a "hang" under the metadata, but rather just normally indented.  The example above is not like that, but rather everything is "flowed" under the def.  I make this point for two reasons:

which approach is really what you want?
I can give you what is in the example above right now

It turns out to be rather easy to do either the normal :arg1-body behavior for def (or whatever) without metadata, and to do the "flow" for any def with metadata.  Here are some examples:
First, the way you don't like:
zprint.core=> (czprint i224a {:parse-string? true})
(deftest ^{:database true, ::test.hooks/system-init-keys system-keys}
         websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

Next, I think this isn't your preferred approach, but it might be better than the one just above -- at least it is like the example you gave last:
zprint.core=> (czprint i224a {:parse-string? true :fn-map {"deftest" [:fn {:list {:option-fn (fn [opts n exprs] (if (meta (second exprs)) {:fn-style :flow-body} {:fn-style :arg1-body}))}}]} :style :community})
(deftest
  ^{:database true, ::test.hooks/system-init-keys system-keys}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

This is the same options map as the previous example, but there is no metadata, so you can see the :arg1-body behavior:
zprint.core=> (czprint i224b {:parse-string? true :fn-map {"deftest" [:fn {:list {:option-fn (fn [opts n exprs] (if (meta (second exprs)) {:fn-style :flow-body} {:fn-style :arg1-body}))}}]} :style :community})
(deftest websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

That is the best I can do without actually changing the code and putting out a new release.  Which I will be doing soon.
Here it is more readably:
(czprint
  i224a
  {:parse-string? true,
   :fn-map {"deftest" [:fn
                       {:list {:option-fn (fn [opts n exprs]
                                            (if (meta (second exprs))
                                              {:fn-style :flow-body}
                                              {:fn-style :arg1-body}))}}]},
   :style :community})

Obviously you will have to change the :fn-map for both def and deftest.  And anything else that you want this behavior for.  I have tested it minimally, but it does appear to work.
It would be nice to have you confirm which approach is really your favorite, since I'm going to try to actually allow that.  I assume it is the first two examples you gave, and not like the third one, the one that I believe you mistakenly thought was already formatted like you wanted (and that the option-fn that I gave, above, produces).  Is that true?

Hey @kkinnear, thanks yep it appears I mistakenly seen the third the same as the first two examples. For some reason I am always bringing you hot potatoes to handle :smile:

what you want from your first two examples is to have the metadata on the same line as the def or deftest, and the symbol on the next line. Also, the symbol is not lined up in a "hang" under the metadata, but rather just normally indented.

Yes that's what I would like to have, but I am ok with the workaround around deftest - the following for now
zprint.core=> (czprint i224a {:parse-string? true :fn-map {"deftest" [:fn {:list {:option-fn (fn [opts n exprs] (if (meta (second exprs)) {:fn-style :flow-body} {:fn-style :arg1-body}))}}]} :style :community})
(deftest
  ^{:database true, ::test.hooks/system-init-keys system-keys}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

looks alright to me - I am not going to apply it to def though or I'll have to change too many places.
...one additional note would be that the meta should behave like a regular map if it gets big - ideally flowing like the third example, but I am sure you've already thought about that.

I'm working toward a real way to get you what you want.  I have some questions.  Which of these do you prefer if the metadata and the symbol would all fit on the same line?
; Version A -- this is now easy

(czprint i224c {:parse-string? true :meta {:split? true}})
(deftest ^{:database true}
  websocket-diagnostic-and-a-bit-more
  (let [foo (bar "1")] foo))

; Version B -- this is what you get today, which is easy, but you don't get version A, above, when
; it doesn't all fit on one line.  I can do this when it fits, and
; do A when it doesn't if that is what you want.

(czprint i224c {:parse-string? true :meta {:split? false}})
(deftest ^{:database true} websocket-diagnostic-and-a-bit-more
  (let [foo (bar "1")] foo))

Also, regarding your comment about the meta map behaving like a regular map if it get big.   It doesn't flow, it hangs the elements of the map:
(czprint "(deftest ^{:database true \n ::test.hooks/system-init-keys \n system-keys :another-map-key :another-map-value}\n\n         websocket-diagnostic-report-measurements-updated-event\n\n  (let [foo (bar \"1\")]\n    foo))\n" {:parse-string? true  :meta {:split? true} :dbg? false})
(deftest ^{:database true,
           ::test.hooks/system-init-keys system-keys,
           :another-map-key :another-map-value}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

Does that work for you?   I can get it to flow the map if it doesn't fit on one line, if you prefer that.  Like this:

; Big map, doesn't fit on one line:

(czprint "(deftest ^{:database true \n ::test.hooks/system-init-keys \n system-keys :another-map-key :another-map-value}\n\n         websocket-diagnostic-report-measurements-updated-event\n\n  (let [foo (bar \"1\")]\n    foo))\n" {:parse-string? true  :meta {:split? true} :dbg? false :list {:hang-expand 0}})
(deftest
  ^{:database true,
    ::test.hooks/system-init-keys system-keys,
    :another-map-key :another-map-value}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

; Small map, fits on one line

(czprint "(deftest ^{:database true \n ::test.hooks/system-init-keys \n system-keys}\n\n         websocket-diagnostic-report-measurements-updated-event\n\n  (let [foo (bar \"1\")]\n    foo))\n" {:parse-string? true  :meta {:split? true} :dbg? false :list {:hang-expand 0}})
(deftest ^{:database true, ::test.hooks/system-init-keys system-keys}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

Is that better?

I'm working toward a real way to get you what you want.

Awesome!

; Version B -- this is what you get today, which is easy, but you don't get version A, above, when
; it doesn't all fit on one line.  I can do this when it fits, and
; do A when it doesn't if that is what you want.

(czprint i224c {:parse-string? true :meta {:split? false}})
(deftest ^{:database true} websocket-diagnostic-and-a-bit-more
  (let [foo (bar "1")] foo))

I think version B is the most common and what most clojurians would expect (apologies if more work), cause most of the times you actually have the metadata map specified as ^:something.
For instance on def you'd have (def ^:private foo "bar") or on a simple kaocha deftest you'd have just a keyword like so:
(deftest ^:database websocket-diagnostic-and-a-bit-more
  (let [foo (bar "1")] foo))

; Big map, doesn't fit on one line:

(czprint "(deftest ^{:database true \n ::test.hooks/system-init-keys \n system-keys :another-map-key :another-map-value}\n\n         websocket-diagnostic-report-measurements-updated-event\n\n  (let [foo (bar \"1\")]\n    foo))\n" {:parse-string? true  :meta {:split? true} :dbg? false :list {:hang-expand 0}})
(deftest
  ^{:database true,
    ::test.hooks/system-init-keys system-keys,
    :another-map-key :another-map-value}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

; Small map, fits on one line

(czprint "(deftest ^{:database true \n ::test.hooks/system-init-keys \n system-keys}\n\n         websocket-diagnostic-report-measurements-updated-event\n\n  (let [foo (bar \"1\")]\n    foo))\n" {:parse-string? true  :meta {:split? true} :dbg? false :list {:hang-expand 0}})
(deftest ^{:database true, ::test.hooks/system-init-keys system-keys}
  websocket-diagnostic-report-measurements-updated-event
  (let [foo (bar "1")] foo))

Is that better?

Yes, this second version is better imho - the previous leaves a lot of "empty space" and you have to move your eyes to the right to note the map. If the metadata map is big it is usually for an "important" reason (in my case system keys are customized) and you should have good perception of that.
I hope this makes sense and thanks for asking and working on this!

Sorry to keep asking, but I'm not having any luck guessing which you prefer.
What about these, where there isn't a map, but they don't fit on the same line?
; Version A is what I was thinking to always do if there wasn't a map in the metadata
; and it doesn't fit on one line (which is what it does today)

zprint.core=> (czprint i224e {:parse-string? true})

(deftest ^:database-stuff-and-bother
         websocket-diagnostic-and-a-bit-more-that-does-not-fit
  (let [foo (bar "1")] foo))

; Version B is, I suppose, an alternative

zprint.core=> (czprint i224e {:parse-string? true :meta {:split? true}})

(deftest ^:database-stuff-and-bother
  websocket-diagnostic-and-a-bit-more-that-does-not-fit
  (let [foo (bar "1")] foo))

Hey, no problem :smile: Version B is best imho

So, I've created a new :style, called :meta-alt in the latest release, 1.2.3.  I have tried really hard to have it include all of the various things we've talked about in this issue.  It is currently marked as "experimental", so I can continue to refine it if necessary.  Why don't you give it a try, and see if it does what you want.  Let me know how it comes out.  Thanks!

Ok sounds good I'll try that and get back to you :smile:

Started comments on the release https://github.com/kkinnear/zprint/discussions/232#discussioncomment-3095766

Back to the actual topic of this issue, I tried to format these:

(deftest
  ^:database
  foo-test
  (testing "foo"
    (is (= :bar :bar))))

(deftest ^{:database true :doc "This is a long comment on the test, so long that is quite
 boring. Not boring in the sense that it is not really telling much but boring in the sense that it
 is very long to read."} comment-test
  (testing "comment"
    (is (= :bar :bar))))

(deftest ^{:database true ::test.hooks/system-init-keys [reporting-service-key ordering-system-key user-service-system-key]} data-test
  (testing "data"
    (is (= :bar :bar))))

with the attached .zprint.edn
and I am very thankful for the result :smile:
(deftest ^:database foo-test
  (testing "foo"
    (is (= :bar :bar))))

(deftest
  ^{:database true
    :doc
    "This is a long comment on the test, so long that is quite
 boring. Not boring in the sense that it is not really telling much but boring in the sense that it
 is very long to read."}
  comment-test
  (testing "comment"
    (is (= :bar :bar))))

(deftest
  ^{:database true
    ::test.hooks/system-init-keys [reporting-service-key ordering-system-key
                                   user-service-system-key]}
  big-data-test
  (testing "data"
    (is (= :bar :bar))))

There is an exception though, I think this one:
(deftest ^{:database true ::test.hooks/system-init-keys system-keys} small-data-test
  (testing "data"
    (is (= :bar :bar))))

Would be better as:
(deftest ^{:database true ::test.hooks/system-init-keys system-keys}
  small-data-test
  (testing "data"
    (is (= :bar :bar))))

There might be something in my config though, that's why I am attaching it this time.

Turns out that in (deftest ^:database foo-test ...) the ^:database parses as a map: {:database true}.  So I can't just change things if I find a map in the metadata.  So I changed it so that if there is more than one key in the map, it will format it on two lines, and if only one key, then one line (as long as it fits).  See if this works for you...
Put this in your zprint.edn:
{:style-map
     {:meta-base
        {:doc "Alternative format for metadata. Experimental.",
         :list {:option-fn
                  (fn ([] "meta-base-option-fn")
                      ([opts n exprs]
                       (when (meta (second exprs))
                         {:meta {:split? true},
                          :list {:hang-expand 0},
                          :fn-style
                            (if (and (map? (meta (second exprs)))
                                     (> (count (keys (meta (second exprs)))) 1))
                              :arg1-body
                              :arg2),
                          :next-inner-restore [[:list :option-fn]
                                               [:list :hang-expand]]})))}},
      :meta-alt {:doc "Alternative for metadata. Experimental.",
                 :fn-map {"def" [:arg2 {:style :meta-base}],
                          "deftest" [:arg1-body {:style :meta-base}]}}}})

This should replace the current :meta-base and :meta-alt styles, and correctly format everything.  This is what I plan to release next, so please let me know how it works.
Thanks!


duplicate page load

Hello, I am using your infinite scroll module, but I found a bug that forces the scroll to work until the limit set is reached, even if there are not enough products for it, and so is appearing duplicate products in the display, I would like to know if it is possible to prevent this duplication?

Thanks for reporting this. Could you please provide step-by-step instructions on how to reproduce this bug, ideally using an out-of-the-box installation of Magento?
If meanwhile you already found a solution then we would also be happy to review a code merge request!


Mobile: rearrange header

Environment: mobile devices
I see several issues regarding the current arrangement of the mobile header:

The category navigation icon currently displays on the right-hand side which is not very common
The store name and the category navigation display on the same line; on smaller screens (example here: example here: iPhone 12 mini, iOS 16.3.1), there is almost no padding between the store name and the category navigation icon. This will become even more prevailing with resolution of https://github.com/Xceptance/posters-demo-store/issues/185.
The user and cart links are part of the main navigation menu which is not very user-friendly. The accessibility of these two needs to be improved.

Suggestions:

Move category navigation icon to the left-hand side and let flyout also expand from the left-hand side
Do not display the full store name but use the X icon only or "X Posters"
Add account icon and cart icon to top navigation
Tap on account opens page where user can either register or log in
Tap on cart opens cart page

Issue not fixed for poster v2.1.
Note:
-Do not display the full store name but use the X icon only or "X Posters" --> not fixed
-Add account icon and cart icon to top navigation--> not fixed
-Tap on account opens a page where user can either register or log in--> not fixed
-Tap on cart opens cart page--> not fixed
-also there is no search bar anymore
-there is another issue (see #199) where the menu isn't working anymore (you can't click the menu button)


Rule to validate the presence of Verbose statements in DSC Resource

good catch. Updated the pull request with changes

Looks good to me.

thanks. I will merge once Appveyor is clean


MQTT Interface

Hi @NickMcSweeney, nice package. It's good to have a Julia MQTT implementation in the ecosystem. I maintain https://github.com/Octogonapus/AWSCRT.jl, which also has an MQTT API. It might be good to try to work out some MQTT interface package which both of our implementations conform to. Not sure that is 100% possible given my package is meant to wrap the AWS CRT as-is, including any oddities it might have, but I figure we could give it a shot. What do you think?

I like the idea. I was just reading through and basically all the "user" facing functions are the same, except Client vs MQTTClient naming, and I have the on_msg callback attached to the client rather than the subscription, plus this doesn't have all the aws stuff in the connection/client.
If this package had MQTTClient(), connect(client, addr, port), subscribe(client, topic, QOS, callback), publish(client, topic, payload, QOS), unsubscribe(client, topic) and disconnect(client); would that be enough? they would be pretty interchangeable at that point I think, or were you thinking something more substantial?
fyi one of my biggest issues with the mqtt implementations for julia has been how the callback was handled, so it is on my list as a thing to change with this package already.

I don't think there is a way to abstract how you get a connection. There are too many implementation-dependent details that are needed. These could be passed through the interface via kwargs, but then you just have a leaky interface. I would leave it out. Same goes for creating the client. Do you feel differently? As precedent, DBInterface.jl does have an empty connect function, but I think it is pretty useless since you need to look to the implementation to know how to use it.
For the other functions, I think we can get away with:

subscribe(callback, connection, topic, qos) callback first for do syntax
publish(connection, topic, payload, qos; retain=false)
unsubscribe(connection, topic)
disconnect(connection)

AWSCRT also has a top-level on_message which I would also put in the interface if this package has it.
We need to define the callback signature: on_message(topic, payload, dup, qos, retain). The arguments dup, qos, and retain, although not typically useful, are returned by the C code, so AWSCRT.jl presents them. Seems like this package doesn't. Would you leave those off?
We need to define the return types of the above functions as well. AWSCRT.jl typically returns a tuple of a task and a packet ID because that is how the C code works. I'm not sure what this package does, or how returning tasks fits in with Dagger.jl.
We need some data types for the connection and QOS:

abstract type Connection end
@enum QOS AT_MOST_ONCE=0 AT_LEAST_ONCE=1 EXACTLY_ONCE=2

Also, this interface should be a separate package MQTTClientInterface.jl, ideally under a shared organization. I'm not sure there is one for messaging; I'll ask around.

fyi one of my biggest issues with the mqtt implementations for julia has been how the callback was handled, so it is on my list as a thing to change with this package already.

What issues were those? I can see how the callbacks in https://github.com/denglerchr/Mosquitto.jl are difficult.
Also you probably should mention https://github.com/rweilbacher/MQTT.jl in the README

Hey, been busy on some other stuff, but I think I have this in the right direction now.

I moved this into a separate project, thought about trying to see if JuliaWeb would take us in, but figured that it would be easier and faster to just put together an MQTT specific project. maybe in the future it turns into JuliaMessaging or something.
I made an interface package https://github.com/JuliaMQTT/MQTT.jl with the idea that we can use the Julia Weak Dependancies for doing the interface. I don't think what I have done so far is something that actually runs, but hopefully it is enough to give the right Idea. I added you to both the project and the repo.

Thanks! I have also been busy but I took a look this morning at what you have done and I think it looks great. Using package extensions is a good idea. I'll try to work on getting the AWS extension working when I have time.

I created the project as JuliaMQTT, I don't think there is a JuliaMessaging project yet, would it be too bold to update the project and see if more than just mqtt stuff wants to go into a shared project location?

I think it is fine if you have other projects in mind.


Send a simple regtest transaction

(!) This depends on #1 and #2 , so there's no point in starting this unless these two are solved
We need to try to send a simplest transaction using regtest wallet. To solve the issue, create a PR that:

Implements the following test

const w = RegTestWallet.fromWIF('....'); // insert WIF from #1
w.send([
  ['bchreg:prc38tlqr6t5fk2nfcacp3w3hcljz4nj3sw247lksj', [1000, 'satoshi']],
]);
expect(RegTestWallet.balanceSats('bchreg:prc38tlqr6t5fk2nfcacp3w3hcljz4nj3sw247lksj')).toBe(1000);

Note that this is not the API the users will use (at least RegTestWallet.balanceSats), it's mostly internal API for us to implement the high-level API (though the send API already high-level).
The address with WIF from #1 should contain some locally mined BCH (25?), so we send them to another address and confirm they are there.
You need to get UTXOs from the local BCHD node (see #2) using GRPC (Some help could be found here), construct a transaction, sign and broadcast it to local BCHD node.
Do it the simplest way possible. If it means using BITBOX for now (you can find some help with it here) to make and sign a transaction, we'll extract the relevant parts later, if you can find a way to use libauth by @bitjson - even better - it's much more light-weight.
Why don't we leave the BITBOX? Well, it's pretty heavy. At read.cash it adds 1MB+ to our app.js
-- $300 bounty --
The bounty is paid in BCH from the funds collected via https://github.com/mainnet-cash/mainnet-js . To claim the bounty, please do the following: if this task requires coding in TypeScript, first you need to complete the test task by sending a private message to ReadCash via Slack link here; 2) after you have completed test task once, tell that you are working on this task and how long it is going to take (if that time expires, anyone else is free to take the task); 3) send a Pull Request or publish the solution here as described in the issue. Good luck! If you think that bounty is way too small, please notify me about it and we can discuss. A bounty will be paid via the chaintip bot.

I can take this on, should be done before 2010-08-15 20h GMT

About 70% of the way through implementing this libauth, +1 day,
Pushing to 2010-08-16 20h GMT

👍
I think "+1 day" is enough as it's pretty easy to match to the "6 minutes ago" that GitHub provides on top of the message. No need for the exact time.

Working on this with libauth here. here:https://github.com/2qx/mainnet-js/tree/feature/3-send-a-simple-regtest-transaction
Starting debugging.  The ssl grpc connections to the local executable are a bit of an issue.

A missive from SSL Hell:
So grpc only connects through ssl, but:

the grpc port has to be opened with a flag on startup (obviously)
when specifying localhost:18335 for the client, it cannot be prepended with https://
the gencerts command utility in bchd doesn't ship with the binary
the certificates generated by gencerts includes alternates for hostname, localhost, and external ips (too much)
there should be a way to override the trust authority of the self-signed certificate, without installing a CA, but haven't quite figured it out.

My goal is to include a self-signed certificate in the repo for DNS:localhost,IP:<IP_ADDRESS> that will work for the developer out of the box without having to trust a root CA.
almost there.
+1 day

So bchd automatically creates certs for the user and puts them in .bchd all we have to do is symlink.
I'm in, it works. On to debugging.

@2qx by the way, you can directly import the built-in P2PKH template from Libauth rather than needing to bundle the template yourself: import { authenticationTemplateP2pkh } from '@bitauth/libauth';
And here's a good usage example:
https://github.com/bitauth/libauth/blob/master/src/lib/transaction/transaction-e2e.p2pkh.spec.ts

@bitjson , thanks, there are a lot of errors in my fork.
I should have a working version shortly.  You library is quite extensive and I like the functional aspect of it.

@bitjson I've got a broken MVP running with ssl using the authenticationTemplateP2pkhNonHd template, here
When I use the utxo from my regtest block bchd complains that it doesn't know about it:
3 INVALID_ARGUMENT: tx rejected: orphan transaction
7cbbe30be6cf0b543b33874807ee6f039a15ac213abc357c6917f3c7f5f99be3
references outputs of unknown or fully-spent transaction
4d0229e507f0f131b9e5ff33f64efae10a6f4156eb0def881e48de39e5fdc87b

I can pull up the utxo from grpcui and confirm that it is indeed there.
Is there something obvious I didn't pickup yet?
These are my big assumptions:
I can send regnet mining rewards right away, correct?,
The arrays for the libauth template are Little-Endian, correct?
Is there anything about the transaction that is obviously wrong, like swapped inputs and outputs?
Or a misuse of something for p2pkh?

Maybe it's a coin age issue? Try generateblocks 100 or 101?

@readcash
So I've tried using a utxo from several hundred blocks ago, but the test transaction still orphans.

I looked in bchd, and the setting to reject orphan transactions are disabled in regtest mode.
I checked grpc-bchrpc-node to make sure the buffer wasn't getting flipped.
It's serving back the input transaction hash with the error code, so I assume it's fine.

I now suspect that the unlocking bytecode is wrong and I'm getting a general error from bchd.
I've hopefully mapped the certificate folders for windows and OS x to the bchd data dir but haven't tested on those platorms.

Good progress! Thanks! Maybe you can try using BITBOX for this, just to test and see if it works? It shouldn't be too hard.

Sorry, I traced the submitTransaction call down in bchd to the point where it gets the utxo from the leveldb cache and it indeed wasn't there.  I flipped the endianness of my tx hash and it was found.  Should be able to wrap this up in a couple of hours.


⚠ Bofrost.fr has degraded performance

In 967f662, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 837 ms

Resolved: Bofrost.fr performance has improved in 12b2a1e after 6 minutes.


fix(deps): update terraform elasticstack to latest for deployable architectures

This PR contains the following updates:

Package
Type
Update
Change

elasticstack (source)
required_provider
patch
0.11.9 -> 0.11.11

Release Notes

elastic/terraform-provider-elasticstack (elasticstack)
v0.11.11
Compare Source

Allow elasticstack_kibana_alerting_rule to be used without Elasticsearch being configured. (#869)
Add resource elasticstack_elasticsearch_data_stream_lifecycle (#838)
Ensure API keys are not replaced when upgrading from 0.11.9 or earlier. (#875)

v0.11.10
Compare Source

Fix bug updating alert delay (#859)
Support updating elasticstack_elasticsearch_security_api_key when supported by the backing cluster (#843)
Fix validation of throttle, and interval attributes in elasticstack_kibana_alerting_rule allowing all Elastic duration values (#846)
Fix boolean setting parsing for elasticstack_elasticsearch_indices data source. (#842)
Update all Fleet and utils/tfsdk instances of diagnostics parameters to pass by pointer instead of pass by value. Added upgrader for fleet_integration_policy v0 to handle empty string vars_json/streams_json. (#855)
Fix handling of EPM packages when uninstalled outside Terraform, and diags in create/update. (#854)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

:tada: This PR is included in version 2.5.16 :tada:
The release is available on:

GitHub release
v2.5.16

Your semantic-release bot :package::rocket:


SLURM version

I'm stuck in this for days now.
In SLURM version, we have added "-S dedup" in the juicer script, there were merged_sort.txt" generated and I see a lot of "splitXXXX" in the aligned folder, and a series of tasks had been submitted to the system. However, there were no tasks were run by the system and there were no further files were generated. So the tasks were stuck for a long time.

We also tried to add "-S dedup -j" in the juicer script, but it can not solve my question,

You will need to contact whoever manages your cluster; if your jobs are
stuck and not running, it's often due to priority or to memory or processor
requirements that your cluster cannot meet. You will have to contact them
to see and possibly tweak the script to match your system's resources.
On Wed, Feb 3, 2021 at 11:03 AM GuangliangGao<EMAIL_ADDRESS>wrote:

We also tried to add "-S dedup -j" in the juicer script, but it can not
solve my question,
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aidenlab/juicer/issues/205#issuecomment-772620003,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAK2EW2Q5XPVLT5LMKKMZDDS5FXUPANCNFSM4XBDJHLQ
.

--
Neva Cherniavsky Durand, Ph.D. | she, her, hers
Assistant Professor |  Molecular and Human Genetics
Aiden Lab | Baylor College of Medicine
www.aidenlab.org

Thanks for your useful advice.
For the administrators of our school cluster server is on vacation，we can not solve the above question in our cluster.
Now we install the juicer CPU version (Juicer version 1.6) on the Dell workstation (72 threads，784 RAM and 80T Hard disk storage) and analyze the HiC data (120G/individual).
I found the content in inter_30.txt is different from that of other analysis, Ligation Motif Present: 0 (0.00%), Intra-fragment Reads: 0 (0.00% / 0.00%), Ligation Motif Present: 0  (0.00% / 0.00%).
Could you help me see if this result is normal ？
The detailed content of the inter_30.txt was listed below:
Experiment description: Juicer version 1.6; BWA 0.7.17-r1188; 50 threads; openjdk version "1.8.0_152-release"; /homeOLD/softwares/opt/juicer/CPU/juicer.sh -z  Chr.genome.deal.fa -d   /topDir -p /juicer/Chr.genome.deal.fa.fai -t 50 -D /homeOLD/softwares/opt/juicer/CPU/ -y /homeOLD/database/goose/juicer/pacbio_MboI.txt
Sequenced Read Pairs:  408,966,683
Normal Paired: 173,659,425 (42.46%)
Chimeric Paired: 203,053,733 (49.65%)
Chimeric Ambiguous: 19,611,208 (4.80%)
Unmapped: 12,642,317 (3.09%)
Ligation Motif Present: 0 (0.00%)
Alignable (Normal+Chimeric Paired): 376,713,158 (92.11%)
Intra-fragment Reads: 0 (0.00% / 0.00%)
Below MAPQ Threshold: 33,036,249 (8.08% / 10.49%)
Hi-C Contacts: 281,798,712 (68.91% / 89.51%)
Ligation Motif Present: 0  (0.00% / 0.00%)
3' Bias (Long Range): 50% - 50%
Pair Type %(L-I-O-R): 25% - 25% - 25% - 25%
Inter-chromosomal: 136,635,410  (33.41% / 43.40%)
Intra-chromosomal: 145,163,302  (35.50% / 46.11%)
Short Range (<20Kb): 67,209,817  (16.43% / 21.35%)
Long Range (>20Kb): 77,935,328  (19.06% / 24.75%)

It's fine, it's because it doesn't know what the ligation junction is.
On Sat, Feb 6, 2021 at 9:04 PM GuangliangGao<EMAIL_ADDRESS>wrote:

Thanks for your useful advice.
For the administrators of our school cluster server is on vacation，we can
not solve the above question in our cluster.
Now we install the juicer CPU version (Juicer version 1.6) on the Dell
workstation (72 threads，784 RAM and 80T Hard disk storage) and analyze the
HiC data (120G/individual).
I found the content in inter_30.txt is different from that of other
analysis, Ligation Motif Present: 0 (0.00%), Intra-fragment Reads: 0 (0.00%
/ 0.00%), Ligation Motif Present: 0 (0.00% / 0.00%).
Could you help me see if this result is normal ？
The detailed content of the inter_30.txt was listed below:
Experiment description: Juicer version 1.6; BWA 0.7.17-r1188; 50 threads;
openjdk version "1.8.0_152-release";
/homeOLD/softwares/opt/juicer/CPU/juicer.sh -z Chr.genome.deal.fa -d
/topDir -p /juicer/Chr.genome.deal.fa.fai -t 50 -D
/homeOLD/softwares/opt/juicer/CPU/ -y
/homeOLD/database/goose/juicer/pacbio_MboI.txt
Sequenced Read Pairs: 408,966,683
Normal Paired: 173,659,425 (42.46%)
Chimeric Paired: 203,053,733 (49.65%)
Chimeric Ambiguous: 19,611,208 (4.80%)
Unmapped: 12,642,317 (3.09%)
Ligation Motif Present: 0 (0.00%)
Alignable (Normal+Chimeric Paired): 376,713,158 (92.11%)
Intra-fragment Reads: 0 (0.00% / 0.00%)
Below MAPQ Threshold: 33,036,249 (8.08% / 10.49%)
Hi-C Contacts: 281,798,712 (68.91% / 89.51%)
Ligation Motif Present: 0 (0.00% / 0.00%)
3' Bias (Long Range): 50% - 50%
Pair Type %(L-I-O-R): 25% - 25% - 25% - 25%
Inter-chromosomal: 136,635,410 (33.41% / 43.40%)
Intra-chromosomal: 145,163,302 (35.50% / 46.11%)
Short Range (<20Kb): 67,209,817 (16.43% / 21.35%)
Long Range (>20Kb): 77,935,328 (19.06% / 24.75%)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aidenlab/juicer/issues/205#issuecomment-774576416,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAK2EW4VOY7VLNJ42NGGCCTS5XYMLANCNFSM4XBDJHLQ
.

--
Neva Cherniavsky Durand, Ph.D. | she, her, hers
Assistant Professor |  Molecular and Human Genetics
Aiden Lab | Baylor College of Medicine
www.aidenlab.org

If you'd sent it -s MboI it would have counted MboI ligation junctions. But
you can get that through a simple grep and the rest of your files are fine.
On Sat, Feb 6, 2021 at 9:47 PM Neva Durand<EMAIL_ADDRESS>wrote:

It's fine, it's because it doesn't know what the ligation junction is.
On Sat, Feb 6, 2021 at 9:04 PM GuangliangGao<EMAIL_ADDRESS>wrote:

Thanks for your useful advice.
For the administrators of our school cluster server is on vacation，we can
not solve the above question in our cluster.
Now we install the juicer CPU version (Juicer version 1.6) on the Dell
workstation (72 threads，784 RAM and 80T Hard disk storage) and analyze the
HiC data (120G/individual).
I found the content in inter_30.txt is different from that of other
analysis, Ligation Motif Present: 0 (0.00%), Intra-fragment Reads: 0 (0.00%
/ 0.00%), Ligation Motif Present: 0 (0.00% / 0.00%).
Could you help me see if this result is normal ？
The detailed content of the inter_30.txt was listed below:
Experiment description: Juicer version 1.6; BWA 0.7.17-r1188; 50 threads;
openjdk version "1.8.0_152-release";
/homeOLD/softwares/opt/juicer/CPU/juicer.sh -z Chr.genome.deal.fa -d
/topDir -p /juicer/Chr.genome.deal.fa.fai -t 50 -D
/homeOLD/softwares/opt/juicer/CPU/ -y
/homeOLD/database/goose/juicer/pacbio_MboI.txt
Sequenced Read Pairs: 408,966,683
Normal Paired: 173,659,425 (42.46%)
Chimeric Paired: 203,053,733 (49.65%)
Chimeric Ambiguous: 19,611,208 (4.80%)
Unmapped: 12,642,317 (3.09%)
Ligation Motif Present: 0 (0.00%)
Alignable (Normal+Chimeric Paired): 376,713,158 (92.11%)
Intra-fragment Reads: 0 (0.00% / 0.00%)
Below MAPQ Threshold: 33,036,249 (8.08% / 10.49%)
Hi-C Contacts: 281,798,712 (68.91% / 89.51%)
Ligation Motif Present: 0 (0.00% / 0.00%)
3' Bias (Long Range): 50% - 50%
Pair Type %(L-I-O-R): 25% - 25% - 25% - 25%
Inter-chromosomal: 136,635,410 (33.41% / 43.40%)
Intra-chromosomal: 145,163,302 (35.50% / 46.11%)
Short Range (<20Kb): 67,209,817 (16.43% / 21.35%)
Long Range (>20Kb): 77,935,328 (19.06% / 24.75%)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aidenlab/juicer/issues/205#issuecomment-774576416,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAK2EW4VOY7VLNJ42NGGCCTS5XYMLANCNFSM4XBDJHLQ
.

--
Neva Cherniavsky Durand, Ph.D. | she, her, hers
Assistant Professor |  Molecular and Human Genetics
Aiden Lab | Baylor College of Medicine
www.aidenlab.org

--
Neva Cherniavsky Durand, Ph.D. | she, her, hers
Assistant Professor |  Molecular and Human Genetics
Aiden Lab | Baylor College of Medicine
www.aidenlab.org

Thanks for your prompt reply


setup.py install of Cython and cykhash breaks in some contexts

Hey! Really neat package! Will love to be a part & contribute.
I've had an adventure to get the module to install with pipenv. First, the module was trying to install with python2.7 because setup.py is executed with /usr/bin/env python which for me (and on many systems) resolves to python2, and same with pip resolving to pip2. I've made a pull request to fix these issues #37 and make installation with python3 more explicit.
The install of Cython and cykhash is indeed a hacky way (as suggested by the comments in file) and I'm super keen to help find a way to make these dependencies resolve more organically. In particular, the explicit installing of these modules via pip doesn't play well with virtual environments/pipenv.
Any ideas on how to make the dependencies resolve in a more self-contained & reproducible manner?

Hi @geoDavey! And thanks for your help, and definitely it would be awesome if you'd be willing to help and contribute to this library! 👍
Indeed, the pip installation is currently a bit hacky as mentioned.. I am at the moment pushing to release pyrosm in conda-forge which would make the installation procedure much more stable/secure using conda, but I think also improving the basic pip installation would be good. Currently the limitation for releasing pyrosm on conda-forge is that Cykhash (one of the dependencies) wasn't published on conda-forge but this should be resolved soon (see here)
For resolving the current dependencies (Cython, OSMPBF/Pyrobuf and Cykhash), I think it might be good to take a look how other Cython dependent libraries are being installed/built, such as pandas and Cykhash. If you want to explore those, I'd be happy to take a PR in. 🙂
I'll comment separately on your PR #37.

@geoDavey Hmm, I am not too familiar with pipenv, but it seems to be another package manager somewhat similar to conda. Do you know if there are any specific reasons to use pipenv instead of conda? I'm just thinking whether it makes sense to start mixing these two package managers together as it seems that pipenv has some own tricks how things should be done..

@geoDavey Okay pyrosm is now available from conda. See #39. I would recommend you to take a look at conda and perhaps migrate using that as your package manager instead of pipenv as it works better with compiled code (such as Pyrosm with Cython). Here's some more information: https://towardsdatascience.com/guide-of-choosing-package-management-tool-for-data-science-project-809a093efd46
In terms of improving the pip installation (removing the "hackish" steps from setup.py), I think using pyproject.toml and uploading the package to PyPi with Flit would be an optimal solution as that seems to be the future of Python packaging (PEP 518). Unfortunately, Flit does not seem to support Cython yet, so this does not really work for pyrosm.

Okay Poetry seems to be a good solution for handling the packaging, short intro: https://hackersandslackers.com/python-poetry-package-manager/

Now also the pip installation is more "clean" and follows PEP 518 style.
Closing this now as the issues here has been resolved:

In terms of pipenv --> please consider using conda for managing your packages.
pip installation was made clean. See #40 for details.

@geoDavey Sorry for not waiting for your replies, but I now had a bit of time to proceed with these, so did not want to wait. Very happy to take in future PRs / issues from you, if you find something to improve or have ideas for new features.


Feature Request: return subtitle name/filename in pool.list_subtitles(video, languages)

@Diaoul
At SickRage we have this code beloew.
Would be better to display subtitles.name instead of subtitles.id so user/devs can debug subtitle picking/downloading
Code:
subtitles_list = pool.list_subtitles(video, languages)
for subtitle in subtitles_list:
    score = subliminal.score.compute_score(subtitle, video, hearing_impaired=sickbeard.SUBTITLES_HEARING_IMPAIRED)
    logger.log(u'[{}] Subtitle score for {} is: {} (min={})'.format
    (subtitle.provider_name, subtitle.id, score, user_score), logger.DEBUG)

Log:
[opensubtitles] Subtitle score for<PHONE_NUMBER> is: 343 (min=367)
[tvsubtitles] Subtitle score for 302989 is: 365 (min=367)
[opensubtitles] Subtitle score for<PHONE_NUMBER> is: 354 (min=367)
Could not search in addic7ed provider. Discarding for now
[opensubtitles] Subtitle score for<PHONE_NUMBER> is: 343 (min=367)
[tvsubtitles] Subtitle score for 302703 is: 365 (min=367)

There's no name attribute in the subtitle and it won't mean anything anyway as the name is rebuilt from the video name.
I think you're looking for #549.


Remove off start-date value in example_dag yaml config

The example_dag in the example_dag_factory.yml has a start_date
value set to 2 days, which seems unclear and problematic. It’s not clear
what this value represents, and it appears to be causing issues with the
DAG, preventing it from running tasks. I confirmed this issue also exists in
version 0.19.0, so it’s not related to any changes made after that version.
When I removed this questionable start_date value, the DAG ran its tasks
successfully.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.96%. Comparing base (a947aa8) to head (6e1ccb7).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #273   +/-   ##
=======================================
  Coverage   93.96%   93.96%
=======================================
  Files           8        8
  Lines         630      630
=======================================
  Hits          592      592
  Misses         38       38

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

shall we remove end_date: 2018-03-05 too?

I guess we can keep it, it does not harm us,  DAG runs are created & run fine until that end_date. And since we have been having it as example like this, I guess good to keep it as is without making much changes. WDYT?

shall we remove end_date: 2018-03-05 too?

I guess we can keep it, it does not harm us, DAG runs are created & run fine until that end_date. And since we have been having it as example like this, I guess good to keep it as is without making much changes. WDYT?

As discussed over Slack, I feel it's good to have that start_date - end_date time window to demonstrate that we're able to run DAGs using DAG factory (accepting those params well), so I'm going ahead with the merge. If the need is to support manual DAG runs, I suggest we create & add another example DAG without having an end_date, but for the given example I strongly believe it's a good example to have an end_date. I am going ahead with the merge now. Thanks for the review & the question :)


Duplicate webservice requests are being sent

Looking at the Firefox dev console Network tab, inspecting what Astral does with nostr.rocks I noticed many duplicate requests:

completely revamped the way I request from the relays and this is fixed! closing.


az storage fs file exists utf-8' codec can't encode characters in position

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az storage fs file exists
Errors:
ERROR: The command failed with an unexpected error. Here is the traceback:
ERROR: 'utf-8' codec can't encode characters in position 35-36: surrogates not allowed
Traceback (most recent call last):
  File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 231, in invoke
    cmd_result = self.invocation.execute(args)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 658, in execute
    raise ex
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 721, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 713, in _run_job
    return cmd_copy.exception_handler(ex)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/storage/__init__.py", line 371, in new_handler
    first(ex)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/storage/__init__.py", line 370, in new_handler
    raise ex
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 692, in _run_job
    result = cmd_copy(params)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 328, in __call__
    return self.handler(*args, **kwargs)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/command_operation.py", line 112, in handler
    client = self.client_factory(self.cli_ctx, command_args) if self.client_factory else None
  File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/storage/_client_factory.py", line 287, in cf_adls_file
    file_path=kwargs.pop('path', None))
  File "/opt/az/lib/python3.6/site-packages/azure/multiapi/storagev2/filedatalake/v2020_02_10/_data_lake_service_client.py", line 494, in get_file_client
    key_resolver_function=self.key_resolver_function)
  File "/opt/az/lib/python3.6/site-packages/azure/multiapi/storagev2/filedatalake/v2020_02_10/_data_lake_file_client.py", line 75, in __init__
    credential=credential, **kwargs)
  File "/opt/az/lib/python3.6/site-packages/azure/multiapi/storagev2/filedatalake/v2020_02_10/_path_client.py", line 71, in __init__
    credential=credential, _hosts=blob_hosts, **kwargs)
  File "/opt/az/lib/python3.6/site-packages/azure/multiapi/storagev2/blob/v2020_02_10/_blob_client.py", line 167, in __init__
    self._client = AzureBlobStorage(self.url, pipeline=self._pipeline)
  File "/opt/az/lib/python3.6/site-packages/azure/multiapi/storagev2/blob/v2020_02_10/_shared/base_client.py", line 136, in url
    return self._format_url(self._hosts[self._location_mode])
  File "/opt/az/lib/python3.6/site-packages/azure/multiapi/storagev2/blob/v2020_02_10/_blob_client.py", line 178, in _format_url
    quote(self.blob_name, safe='~/'),
  File "/opt/az/lib/python3.6/urllib/parse.py", line 819, in quote
    string = string.encode(encoding, errors)
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 35-36: surrogates not allowed

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Set a files on a blob containing é è   french character like 131318-(n) Hamilton Densité.JPG
az storage fs file exists --path {} --account-name {} --account-key {} --file-system {}

Expected Behavior
should return true or false
under windows os , no problem
Environment Summary
Linux-5.4.72-microsoft-standard-WSL2-x86_64-with-debian-bullseye-sid, Ubuntu 20.04.3 LTS
Python 3.6.10
Installer: DEB

azure-cli 2.32.0 *

Additional Context

storage

Unusual for english speaker yes, usual in french  :-)   character like  é è ç °
The strange stuff it is that under windows os with git terminal, no problem.
Same code under ubuntu docker , then problem arise

Hi @evelyn-ys Yishi, I did some testing on this and can confirm that the Datalake SDK does support these types of Unicode characters on Linux (tested on Ubuntu 18.04). I was able to create, update, check existence, and read a file with the name "131318-(n) Hamilton Densité.JPG". I tried both hardcoding the name in a string and accepting the file name from the terminal.
My guess is that this has something to do with how CLI reads in the file path string before sending to the SDK. I did a bit of research on this topic/error, and it seems that reading in file paths on Linux can add surrogates for non-supported characters when trying to convert to Unicode. The surrogates will then break any attempts to decode the string, like when the SDK is trying to URL encode the string. Here is a Stack Overflow that I found on the issue.
It seems like the CLI may need to do something to handle file names with non-default encodings. The Stack Overflow has a couple of suggestions.


Stop setting DeprecatedVisibility to child ingress

This patch removes DeprecatedVisibility from child ingress
DeprecatedVisibility is deprecated for a long time and actual
visibility is correctly set as:
https://github.com/knative-sandbox/net-contour/blob/2555e84b6b2f39ef524e6a98e1ec03f87ced9c46/pkg/reconciler/contour/resources/kingress.go#L116
Hence this patch stops setting it.
/cc @dprotaso

Friendly ping @dprotaso

/lgtm
/approve


Unable to allocate

Describe the bug
Trying to run alpha-DIA phospho-enriched of 3 samples using timsTOF-pro using version 1.8.1

but facing following error
9 days, 5:25:09.773994 ERROR: Search for zr_IMAC_300ug_zoom20_1dia_25pepsep_S1-A8_1_8451 failed with error: Unable to allocate 2.21 GiB for an array with shape (46, 12921749) and data type float32
Traceback (most recent call last):
  File "alphadia\planning.py", line 342, in run
    psm_df, frag_df = workflow.extraction()
                      ^^^^^^^^^^^^^^^^^^^^^
  File "alphadia\workflow\peptidecentric.py", line 838, in extraction
    features_df, fragments_df = self.extract_batch(
                                ^^^^^^^^^^^^^^^^^^^
  File "alphadia\workflow\peptidecentric.py", line 816, in extract_batch
    features_df, fragments_df = candidate_scoring(
                                ^^^^^^^^^^^^^^^^^^
  File "alphadia\plexscoring.py", line 1915, in __call__
    candidate_features_df = self.collect_candidates(candidates_df, psm_proto_df)
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "alphadia\plexscoring.py", line 1768, in collect_candidates
    df = utils.merge_missing_columns(
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "alphadia\utils.py", line 683, in merge_missing_columns
    return left_df.merge(right_df[on + missing_from_left], on=on, how=how)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

To Reproduce
Steps to reproduce the behavior:

Go to 'Input files' and add data

Set up parameters

Click on 'Run workflow'

Logs
Please provide the log (see the AlphaDIA terminal on where to find it).
Method Setup
CPU: 2.69%
RAM: 26.90 GB / 127.92 GB (21.03%)
3 days, 5:52:24.788294 INFO: calibration group: precursor, fitting mz estimator
3 days, 5:52:24.890499 INFO: calibration group: precursor, fitting rt estimator
3 days, 5:52:24.989609 INFO: calibration group: precursor, fitting mobility estimator
3 days, 5:52:25.088798 INFO: calibration group: fragment, fitting mz estimator
3 days, 5:52:25.436969 INFO: calibration group: precursor, predicting mz
3 days, 5:52:25.469558 INFO: calibration group: precursor, predicting rt
3 days, 5:52:25.556145 INFO: calibration group: precursor, predicting mobility
3 days, 5:52:25.588838 INFO: calibration group: fragment, predicting mz
3 days, 5:52:25.946824 INFO: === checking if optimization conditions were reached ===
3 days, 5:52:25.947829 PROGRESS: === Optimization of mobility_error has been performed 3 time(s); minimum number is 2 ===
3 days, 5:52:25.951378 PROGRESS: \u2705 mobility_error : optimization complete.  Values taken forward for search are:
3 days, 5:52:26.532031 PROGRESS: ==============================================
3 days, 5:52:26.532031 PROGRESS: ms2_error      : 10.0000
3 days, 5:52:26.532031 PROGRESS: ms1_error      : 5.0000
3 days, 5:52:26.533010 PROGRESS: rt_error       : 697.5405
3 days, 5:52:26.533010 PROGRESS: mobility_error : 0.0751
3 days, 5:52:26.534011 PROGRESS: ==============================================
3 days, 5:52:26.550471 INFO: calibration group: precursor, predicting mz
3 days, 5:52:29.037010 INFO: calibration group: precursor, predicting rt
3 days, 5:52:35.841354 INFO: calibration group: precursor, predicting mobility
3 days, 5:52:38.326065 INFO: calibration group: fragment, predicting mz
3 days, 5:53:06.057718 PROGRESS: Extracting batch of 8106263 precursors
3 days, 5:53:08.930254 INFO: Duty cycle consists of 11 frames, 1.17 seconds cycle time
3 days, 5:53:08.930254 INFO: Duty cycle consists of 928 scans, 0.00082 1/K_0 resolution
3 days, 5:53:08.930254 INFO: FWHM in RT is 5.92 seconds, sigma is 1.07
3 days, 5:53:08.931255 INFO: FWHM in mobility is 0.007 1/K_0, sigma is 3.87
3 days, 5:53:08.937792 INFO: Starting candidate selection

  0%|          | 0/1000 [00:00<?, ?it/s]
  0%|          | 1/1000 [00:00<02:16,  7.33it/s]
  0%|          | 2/1000 [07:10<70:08:58, 253.05s/it]
  0%|          | 3/1000 [14:43<95:27:31, 344.69s/it]
  0%|          | 4/1000 [22:35<109:10:50, 394.63s/it]
  0%|          | 5/1000 [30:26<116:42:03, 422.23s/it]
  1%|          | 6/1000 [38:16<121:03:11, 438.42s/it]
  1%|          | 7/1000 [46:08<123:57:18, 449.38s/it]
  1%|          | 8/1000 [54:03<126:04:48, 457.55s/it]
  1%|          | 9/1000 [1:01:50<126:49:38, 460.72s/it]
  1%|1         | 10/1000 [1:09:47<128:00:42, 465.50s/it]
  1%|1         | 11/1000 [1:17:17<126:38:55, 461.01s/it]
  1%|1         | 12/1000 [1:24:27<123:52:59, 451.40s/it]
  1%|1         | 13/1000 [1:31:40<122:13:56, 445.83s/it]
  1%|1         | 14/1000 [1:38:51<120:54:36, 441.46s/it]
  2%|1         | 15/1000 [1:45:59<119:40:16, 437.38s/it]
  2%|1         | 16/1000 [1:53:09<118:53:53, 434.99s/it]
  2%|1         | 17/1000 [2:00:19<118:24:07, 433.62s/it]
  2%|1         | 18/19 days, 1:38:41.329861 INFO: Applying score cutoff of 18.306091209411623
9 days, 1:38:42.386940 INFO: Removed 1473214 precursors with score below cutoff
9 days, 1:38:53.946519 INFO: Starting candidate scoring

  0%|          | 0/1000 [00:00<?, ?it/s]
  0%|          | 2/1000 [00:04<39:30,  2.38s/it]
  0%|          | 3/1000 [00:10<59:49,  3.60s/it]
  0%|          | 4/1000 [00:16<1:14:32,  4.49s/it]
  0%|          | 5/1000 [00:22<1:23:21,  5.03s/it]
  1%|          | 6/1000 [00:28<1:28:15,  5.33s/it]
  1%|          | 7/1000 [00:33<1:31:21,  5.52s/it]
  1%|          | 8/1000 [00:39<1:33:30,  5.66s/it]
  1%|          | 9/1000 [00:45<1:34:52,  5.74s/it]
  1%|1         | 10/1000 [00:51<1:36:05,  5.82s/it]
  1%|1         | 11/1000 [00:57<1:35:35,  5.80s/it]
  1%|1         | 12/1000 [01:02<1:30:42,  5.51s/it]
  1%|1         | 13/1000 [01:06<1:25:55,  5.22s/it]
  1%|1         | 14/1000 [01:11<1:22:56,  5.05s/it]
  2%|1         | 15/1000 [01:16<1:20:56,  4.93s/it]
  2%|1         | 16/1000 [01:20<1:19:03,  4.82s/it]
  2%|1         | 17/1000 [01:25<1:17:31,  4.73s/it]
  2%|1         | 18/1000 [01:29<1:16:47,  4.69s/it]
  2%|1         | 19/1000 [01:34<1:16:35,  4.68s/it]
  2%|2         | 20/1000 [01:39<1:9 days, 5:24:44.546288 INFO: Finished candidate processing
9 days, 5:24:44.548306 INFO: Collecting candidate features
9 days, 5:25:09.773994 ERROR: Search for zr_IMAC_300ug_zoom20_1dia_25pepsep_S1-A8_1_8451 failed with error: Unable to allocate 2.21 GiB for an array with shape (46, 12921749) and data type float32
Traceback (most recent call last):
  File "alphadia\planning.py", line 342, in run
    psm_df, frag_df = workflow.extraction()
                      ^^^^^^^^^^^^^^^^^^^^^
  File "alphadia\workflow\peptidecentric.py", line 838, in extraction
    features_df, fragments_df = self.extract_batch(
                                ^^^^^^^^^^^^^^^^^^^
  File "alphadia\workflow\peptidecentric.py", line 816, in extract_batch
    features_df, fragments_df = candidate_scoring(
                                ^^^^^^^^^^^^^^^^^^
  File "alphadia\plexscoring.py", line 1915, in __call__
    candidate_features_df = self.collect_candidates(candidates_df, psm_proto_df)
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "alphadia\plexscoring.py", line 1768, in collect_candidates
    df = utils.merge_missing_columns(
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "alphadia\utils.py", line 683, in merge_missing_columns
    return left_df.merge(right_df[on + missing_from_left], on=on, how=how)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "pandas\core\frame.py", line 10832, in merge
  File "pandas\core\reshape\merge.py", line 184, in merge
  File "pandas\core\reshape\merge.py", line 888, in get_result
  File "pandas\core\reshape\merge.py", line 879, in _reindex_and_concat
  File "pandas\core\reshape\concat.py", line 395, in concat
  File "pandas\core\reshape\concat.py", line 684, in get_result
  File "pandas\core\internals\concat.py", line 131, in concatenate_managers
  File "pandas\core\internals\concat.py", line 230, in _maybe_reindex_columns_na_proxy

Version (please complete the following information):

Installation Type : One-Click Installer

Platform information

system    Windows 11
machine   x86_64
cpu count 24

Python information:

alphadia version 1.8.1

Additional context
phoSTY mods

Hi,
This seems to be a memory issue. We currently only have limited support for searching large libraries with timsTOF.
How many files were processed before alphaDIA crashed?
There a re a couple of things worth trying:

set the number of candidates in the Search tab to 1
reduce the missed cleavages to 1

Some other observatios which should not affect memory but search speed:

The number of threads looks relatively low for 24 cores. Maybe something like 20 would be better
The mass accuracy is a bit low for timsTOF data. I would recomend 15ppm on the MS1 and MS2 level.

Best,
Georg

Thanks @GeorgWa for the suggestions 💯 There are 3 input files and I must note that i appended ;Phospho(STY) to the Mod-list, is that the correct way to go about it?

Yes, the configuration looks correct.
You can find an overview of all modifications here
I think Phospho@S;Phospho@S;Phospho@Y should be the correct mod definition.
Can you also try to not set Acetyl and MethionineOX as variable modification?


this paper doesn't seem to load 1707.06347

Exact location of issue
https://ar5iv.labs.arxiv.org/html/1707.06347
Problem details
no text

Thank you for the report!
The arXiv submission never included a real TeX source, just a technique to ingest a precompiled PDF. The source in question here is:
\documentclass[a4paper]{article}
\pdfoutput=1
\usepackage{hyperref}
\hypersetup{
  pdfinfo={
    Title={},
    Author={}
  }
}
\usepackage{pdfpages}

\begin{document}
\includepdf[pages=1-last]{ppo-min.pdf}
\end{document}

This is identical to the problem in #376 , and sadly we have no avenue to resolution from the ar5iv side. The only realistic change is for the arXiv to resubmit an update basewd on the actual TeX of the article, for arXiv to compile through.
So I am resolving with "wontfix" for now.


What's the state of the art on Nerf compression?

@ashawkey friendly ping
We are reaching a point where text/2D to 3D assets are of sufficiently high quality to be used as assets in indie video games.
The issue as for the practicality of this is at least two folds:

the performance of the renderer which I believe is a mostly solved problem at least I've seen many papers claiming > 30FPS
the size of the 3D asset.
I believe that current 3D generated assets of relatively simple objects have considerable weight (MB? GB?) but I also believe this is highly compressable.
for exemple in many games one can afford to have "hollow" solid objects where only the surface is drawn and where the points inside the object are empty since they're not visible.
Nerf 3D generators fills the interior of objects but I believe those mostly useless points could be removed as a post prossessing step.

There are other kinds of optimisations that might be possible such as some artefacts smoothings, and conditional rendering of pixels based on clipping/occlusion.
One might even try to train a neural network for the task of compressing a nerf 3D asset without reducing its perceived accuracy or 3D external boundaries, or simply develop a classical optimizer.
So whats the state of the research on making 3D assets actually usable in video games with a reasonable size?

Plenty of tools available that will hollow out a model if you can't do it manually.
Personally though, unless for some reason you would rather spend long periods of time letting the computer generate background-assets than bang them out yourself, I would wait for Nvidia Picasso.
Who knows tho? This is all happening so very fast.

@Ainaemaet
Thank you! I had not heard of Picasso and it looks very promising from a user experience standpoint, though I wonder if the accuracy of https://fantasia3d.github.io/ is better.

unless for some reason you would rather spend long periods of time letting the computer generate
Fantasia3d currently take "on average" 30-35 minutes to generate a 3D asset with a 8X RTX3090 gpus setup
I wonder how fast picasso will be. I also believe that researchers have not yet attempted to improve inference/generation time, for example they might benefit significantly from deepspeed including INT8 precision or even maybe INT4, and LORA or NERF specific optimisations.


STEMN is able to parse LaTeX code as math equations. GitHub does not support LaTeX.
One possible alternative is 1TeX2img, which converts LaTeX to an image that may be embedded on the page.

[bug] Equations need to be displayed properly (using images or otherwise).
[help wanted] All existing equations must be fixed.

Looks like latex isn't going to be supported anytime soon https://github.com/github/markup/issues/274

This is closely related to #6 - I've just found out that Sphinx imgmath has LaTeX support. :+1:

Correct. This issue is encapsulated by issue #6. Closing this issue.


Default mapping and gestures - Analysis and ideas

Please provide your feedback on the following idea for the default layout and gestures! The possibility that in the future one can freely map to both (layout is already possible) notwithstanding, of course.
For brevity, I shall abbreviate the sectors ([:sector:]) as T (Top), R (Right), L (Left), B (Bottom), and C (Inside_circle) in regex:
The typing sequences from touch to release are currently (C[[:sector:]]+)+C([[:sector:]]*) where the second capture group of trailing [[:sector:]]s, if not empty, only has the effect of omitting a trailing <space> but is not further differentiated. This could potentially be changed (for example, only one specific sector omits the trailing space), but I think it should be kept.
The above leaves all sequences which

don't start in the circle ([[:sector:]]+C)*[[:sector:]]*
The 12 most simple of these are lines which start at a sector and terminate immediately (tap the sector), go to the circle (swipe inwards), or cross the circle into the opposing sector (swipe across). I propose the following bindings to them:

T: Shift (unchanged)

TC: Copy (mnemonic: pull the contents towards you, off the screen)

TCB: Cut (mnemonic: a "stronger" and longer version of Copy)

R: Backspace (unchanged)

RC: Select all (mnemonic: the cursor is at the end of the text and you want to select everything before)

RCL: Pos1 (mnemonic: all the way back)

L: Number-Pad or more generally the grid-layout (unchanged)

LC: Tab (mnemonic: a bit like CR)

LCR: End (mnemonic: opposite of Pos1; all the way forth)

B: Return (unchanged)

BC: Paste (mnemonic: push the clipboard onto the screen)

BCT: Emoji-Keyboard (mnemonic: paste an Emoji)
NB on changes: TCB is currently meant to hide the keyboard, but this is not needed because Android provides a button for it, as far as I know. RC is currently bound to bringing up the selection keyboard, all of whose functions would now be available as gestures. The selection keyboard could still be opened with the sidebar button.

never return to the circle C[[:sector:]]+
The 4 most simple of these -- besides the tap in the circle for <space> -- are the ones which swipe outside. They are currently bound to the direction arrows (move the cursor), and I think this is a good choice which should be kept.

With these bindings, all the current sidebar buttons would be optional:

The Emoji-Keyboard is available as a gesture
Tab is available both, as a dedicated gesture and from the CR gesture if the cursor is at the end of an input field
All functions in the selection keyboard are available as gesture
Settings can be accessed through Android System Settings

For aid, the three gestures per sector from the 1st group could be indicated as three icons (instead of one icon currently).

Android does provide buttons to hide the keyboard, but they are not always visible (an on screen, keyboard-specific button does not show up with gesture controls), nor clear (shared functionality with the back button), so I've found the current use of TCB to be surprisingly useful. Keeping that functionality would be preferred, even if it's shifted to an odd gesture like RCB ("backspace the keyboard down").
The proposed use for RCL and LCR overlap a bit with CT and CB, as well as just tapping at the beginning and end of the text and correcting if it's off by a few characters with the keyboard. I'd propose placing Pos1 and End on gestures like Shift+CT or CTC. That would keep all cursor manipulation originating from C. This could also permit intuitive home and end key functionality with CRC/CLC.
I hadn't noticed this before playing around with functionality for this post, but selecting and launching into the selection keyboard from RC+hold is very useful. Maybe this could be preserved and expanded with RCL as back select and LCR as forward select gestures?

Thank you for the feedback.

I hadn't noticed this before playing around with functionality for this post, but selecting and launching into the selection keyboard from RC+hold is very useful.

I've wrongly written LC would currently bring up the selection keyboard. Of course, this is supposed to be RC, as you rightfully wrote there!

Android does provide buttons to hide the keyboard, but they are not always visible [...]

I am not experienced with the variety of Androids and their UX/UI, so I appreciate that new perspective on this. In general, I'd say that if, "in theory", Android is supposed to provide that function and is just bad at doing so (for me it works well), then incorporating that function into the keyboard itself is a work-around. A work-around, which is hopefully only temporary in nature until Android improves to live up to "the theory". Hence, I think putting "hide keyboard" on a less optimal gesture such as RCB is a good idea.

The proposed use for RCL and LCR overlap a bit with CT and CB, [...].  Maybe this could be preserved and expanded with RCL as back select and LCR as forward select gestures?

Although I do not see how said "overlap" is a problem (mind to elaborate?), I think you point out a good alternative. I would rather not bind to C[[:sector:]]C, though, because of #240, but binding to Shift-CT and Shift-CB seems like a viable alternative. Pos1 and End are relatively rare and requiring a tap on Shift wouldn't be a worry. I think Shift-C[RL] is a bit more intuitive because I associate Pos1 and End with horizontal movements, but either of those is fine.

but selecting and launching into the selection keyboard from RC+hold is very useful.

Was that your motivation for liberating LCR and RCL? If so, then I can not relate, because either you are a "power user" and make full use of the gestures, in which case all the functions of the selection keyboard are already accessible. Or you are not comfortable with the gestures and you want buttons of the selection keyboard; but in that case you have the dedicated "Selection-Keyboard" button. Do you require a gesture to open the selection keyboard, if you're not using gestures to perform the functions therein?

Although I do not see how said "overlap" is a problem (mind to elaborate?)

It's not really a problem, I was just considering more optimal use of RCL/LCR. Those are prime gestures, if you will, and might be more suited for more common use cases. (further opinions included below)

...either you are a "power user" and make full use of the gestures, in which case all the functions of the selection keyboard are already accessible.

The gestures do not handle selection of text well, unfortunately, and I don't think there's an easy way to mimic the arrows from the selection keyboard--particularly the ability to toggle between tweaking  the beginning or end of the active selection. The current functionality of RC allows me to select the last sentence I wrote by holding the gesture and launches me directly into the selection keyboard upon release so I can tweak for precision (useful because timing the end of a selection is tricky).
I just thought this was a nifty feature and am interested in its preservation. I'll definitely be customizing my layout as soon as I find documentation, so I'm not overly concerned about these ideas making it into the defaults.

Do you require a gesture to open the selection keyboard, if you're not using gestures to perform the functions therein?

If the goal of builiding out full gesture support is to pave the way for an option to hide the sidebar buttons, I would find it handy!

The gestures do not handle selection of text well, unfortunately, and I don't think there's an easy way to mimic the arrows from the selection keyboard--particularly the ability to toggle between tweaking the beginning or end of the active selection.

I see. What do you think about the following mappings, then?

RCL: Extend selection towards the left
LCR: Extend selection towards the right
CL: Shrink selection at the right end; if 0 wide (only a cursor), move the cursor left
CR: Shrink selection at the left end; if 0 wide (only a cusor), move the cusor right
Shift-CL: Place cursor at left end of selection; if 0 wide, act as Pos1
Shift-CR: Place cursor at right end of selection; if 0 wide, act as End

If that's not satisfactory, could you describe a sequence of inputs where you'd require more?

Those mappings sound good. If I understand correctly, the premise is RCL and LCR start a selection and the cursor movements switch function to help adjust the selection (by reducing the selection in your example). Shift+CL breaks the selection and leaves the cursor at the start point, and Shift+CR at the end point.
This covers most cases and would greatly reduce the need for the selection keyboard. The last use case the selection keyboard would perform better for is selecting larger blocks of text, like paragraphs (via the up and down arrows).
To achieve full parity, I'd propose shifting things around a bit to adapt LCR, RCL, TCB, and BCT as "cursor+" gestures. Here's the idea:
Without selection:
C* -> standard cursor movements, hold to repeat
LCR, RCL -> home, end (of current line); hold to start selection left or right
BCT, TCB -> pos1, end (of text); hold to start selection up or down
With selection:
C* -> move end selection position left, right, up, or down; hold to repeat
C -> move start selection left, right, up, or down; hold to repeat
Shift+C* -> break selection and jump to start[LT]/end[RB]
With anything:
TLBRT -> emoji keyboard
Shift+TC -> cut
Once again, this is just throwing ideas out there. I feel there are a few compromises in this proposal, one being contextual copy/cut, which may cause unintended mistakes. The cursor+ gestures may also be jarring with a forward select functionality, initially capturing a selection from posA to posB and then "switching" to control the selection at posA.
I hope this is helpful feedback. I can definitely work with any of the proposed changes, and getting a copy function in the gestures will by itself be a huge QOL improvement!


websocket not supported on one device

Hi, i'm getting the hang of the editor, usefull stuff. For now i have a very basic gui with 2 buttons. The website shows in my browser of my desktop and on my son's tablet (latest android). I'm getting a error on my older android 3.1 tablet though 'websocket not supported on device or server unreachable' after that the page loads but stays greyed out with a blue square in the top center. In the terminal i can see the device's ip connecting and then a message '"GET /res/style.css?7e7421c8fede27d23793172efe65d3d9 HTTP/1.1" 200 -' but no handshake after that.
I tried different browsers on that tablet but all give the same message. Problem is that the final design should be displayed on that tablet. Is there a way i can fix this? Thx !

Hello @trex78 , unfortunately there is no fix for this. You should update the android webengine, or search for other browser. which browsers you tried?

operam mini, default android broswer, dolphin, uc browser, overskreen. Too bad, really liked this project.


CORE-4356 CPB Tool

WIP

What's the reason for this to be in this repo?
Is there guidance somewhere for when we put plugins in corda-runtime-os and when not?
We should not have plugins in this repo IMO, either the repo name is wrong, or plugins must be somewhere else.

This is a good point. I think we said with @josephzunigadaly that we should be moving them (at least CPx ones but probably all of them) in corda-runtime-os. But perhaps in a subsequent PR. @josephzunigadaly could you please confirm.


[cocoon] CQ is broken due to build runner timeouts

It's timing out when running the build_runner logic on app_dart
"No published analyzer available for language version 2.14.0".

$ dart run build_runner build --delete-conflicting-outputs
[INFO] Generating build script completed, took 308ms
[WARNING] Deleted previous snapshot due to missing asset graph.
[INFO] Creating build script snapshot... completed, took 10.6s
[INFO] Building new asset graph completed, took 621ms
[INFO] Checking for unexpected pre-existing outputs. completed, took 1ms
[WARNING] json_serializable:json_serializable on bin/server.dart:
Your current `analyzer` version may not fully support your current SDK version.

Please try upgrading to the latest `analyzer` by running `flutter packages upgrade`.

Analyzer language version: 2.12.0
SDK language version: 2.14.0

If you are getting this message and have the latest analyzer please file
an issue at https://github.com/dart-lang/sdk/issues/new with the title
"No published analyzer available for language version 2.14.0".
Please search the issue tracker first and thumbs up and/or subscribe to
existing issues if present to avoid duplicates.

[SEVERE] json_serializable:json_serializable on bin/server.dart:

Bad state: Unexpected diagnostics:
/usr/local/google/home/chillers/Documents/flutter/bin/cache/dart-sdk/lib/core/int.dart:117:18 - Operator declarations must be preceded by the keyword 'operator'.
/usr/local/google/home/chillers/Documents/flutter/bin/cache/dart-sdk/lib/core/int.dart:117:18 - A function body must be provided.
/usr/local/google/home/chillers/Documents/flutter/bin/cache/dart-sdk/lib/core/int.dart:117:16 - Methods must have an explicit list of parameters.
[SEVERE] json_serializable:json_serializable on bin/server.dart:

https://ci.chromium.org/p/flutter/builders/try/Cocoon

Changing as P1 as it is affecting multiple CLs in recipes and multiple PRs in cocoon.

My investigation yesterday showed this is non-trivial. There isn't an easy path forward as we need to make Cocoon's app_dart compatible with analyzer: ^1.0.0 which requires migrating to NNBD packages. This is mostly doable, except package:gcloud does not have an available NNBD version.
A short term fix would be to move Cocoon out of customer_tests and to move to the stable version of Dart, but we'd still need to actively work on this before this dev is promoted to stable (ETA few weeks).
I'm going to try migrating app_dart to NNBD in the minimum way possible today, and seeing if that unblocks. Otherwise, I'll downgrade the Flutter channel to stable by EOD.

Sounds good, thanks for the update!

Cocoon deploys are fixed, Cocoon CQ is unblocked, and recipes are testing Cocoon again. Downgrading to P3 as this requires follow up over several weeks to ensure the linked PRs land to support NNBD in the backend's dependencies.

The new Flutter stable was released yesterday, and this is now broken (I mixed up the release calendar and expected it to release next week).
This is my top priority