[RFC][meta] Notes on Immutability and Reducing Risk of Validator Collusion

Background
Libra is a permissioned blockchain with a federation of validators/block proposers. The most common argument against such a setup is the possibility of collusion by that authority set. For many users, the (albeit unlikely) ability of validators to coordinate and alter the history of the chain creates a reasonable amount of doubt in the system's immutability — one of the core tenets of blockchain engineers and enthusiasts. Such a situation can, of course, be avoided by using traditional Proof of Work (PoW). For reasons described at length elsewhere, this is not ideal for Libra "due to their poor performance and high energy (and environmental) costs."
Proposal
So long as some PoW based system exists, however, it is possible for another chain to piggyback on the immutability of that system through "anchoring". For each newly committed block (or set of blocks) in Libra, a transaction is submitted to a sufficiently large PoW chain (e.g. Bitcoin). The transaction's payload contains a cryptographic commitment to those new blocks. Libra validators can continue processing and committing new blocks at the intended throughput, while also achieving a level of immutability comparable to the parent chain.
Anchoring is not intended to be a part of consensus. It is a separate, minimal service that few entities would run along-side normal operation of the Libra protocol as a means of creating an auditable history of the protocol's operation. While any sufficiently trusted PoW chain would suffice, for the sake of simplicity and familiarity, Bitcoin will be used as the primary example moving forward. In theory, this simple scheme is blockchain agnostic and can be applied to any immutable parent ledger with slight modifications to transaction structure.
LibraBFT can be summarized with the following overview taken from the Libra consensus component README:

In LibraBFT, validators receive transactions from clients and share them with each other through a shared mempool protocol. The LibraBFT protocol then proceeds in a sequence of rounds. In each round, a validator takes the role of leader and proposes a block of transactions to extend a certified sequence of blocks (see quorum certificates below) that contain the full previous transaction history. A validator receives the proposed block and checks their voting rules to determine if it should vote for certifying this block. These simple rules ensure the safety of LibraBFT — and their implementation can be cleanly separated and audited. If the validator intends to vote for this block, it executes the block’s transactions speculatively and without external effect. This results in the computation of an authenticator for the database that results from the execution of the block. The validator then sends a signed vote for the block and the database authenticator to the leader. The leader gathers these votes to form a quorum certificate that provides evidence of $\ge$ 2f + 1 votes for this block and broadcasts the quorum certificate to all validators.
 A block at round k is committed if it has a quorum certificate and is confirmed by two more blocks and quorum certificates at rounds k + 1 and k + 2.  LibraBFT guarantees that all honest validators will eventually commit the block (and proceeding sequence of blocks linked from it). Once a sequence of blocks has committed, the state resulting from executing their transactions can be persisted and forms a replicated database.

A single Bitcoin transaction can contain 80 bytes of arbitrary data. Using this space, a Libra anchor can be represented by including a hash of the highest committed Quorum Certificate.
The goal of the anchoring service is to include one transaction in every Bitcoin block, covering all newly produced Libra blocks. This is not to say that every Libra block needs a corresponding anchor, though. For example, an anchor submitted for block 100's QC also implicitly covers blocks 0 through 99 as a QC is already commitment of a state change based on the previous blocks. Thus, we are able to have only one anchor transaction in flight at any given point in time.
On creation of a new Bitcoin block:
1) check DB for TX-ID of last submitted anchor transaction
2) query Bitcoin node for it's status:
        transaction does not exist:
            submit new anchor transaction for highest Libra QC
        transaction exists and is still pending:
            perform a "replace-by-fee" for a new anchor transaction using highest Libra QC
        transaction exists and was confirmed:
            resubmit info about the confirmed anchor back into Libra, using a Move resource (if the operator wants to publish their anchors for others)
            submit new anchor transaction for highest Libra QC
3) save the new transaction locally as a pending anchor

The "replace-by-fee" strategy will ensure that even in times of high-traffic, we will always be attempting to anchor the most recent Libra block. On the topic of cost, a single anchor per Bitcoin block would run approximately $0.50 (average tx) * 144 (tx/day) * 365 = $26,280. This cost could be higher or lower depending on traffic, but regardless, it is negligible compared to the amount of resources being poured into achieving the same level of imutability in Bitcoin PoW.
Surely there are implementation details that would need ironed out. The above description aims to illustrate that it is possible to enhance the immutability of Libra with relatively little technical complexity or financial overhead.
Thoughts and Future Considerations
Who would run this?
As it requires the operator to spend small amounts of BTC per anchor, this would likely be a voluntary effort at first, done as a courtesy to the community. Individuals would reserve the choice to perform their own independent anchoring, of course. Though it is easier and arguably just as effective to continuously audit the anchors produced by another entity that publishes their anchors (on-chain or otherwise). As the Libra ecosystem progresses towards full decentralization — or as the need arises due to consistently high Bitcoin fees — it might make sense to publicly subsidize the creation of anchors, incentivizing their submission or auditing.
Is one anchor per Bitcoin block necessary?
No, it doesn't really need to be every block. Aiming to put an anchor in every block simply brings Libra to a level of immutability similar to Bitcoin. It would be worth exploring the right balance, though. Perhaps once every 6 Bitcoin blocks would suffice — only submitting the next anchor when the previous one has hit 6 confirmations.

Although implementation is rather trivial and I would be willing to open a PR, I was hoping to hear what others in the community think about the idea before moving forward. My knowledge of the Libra ecosystem is far from complete at this point, and would appreciate any insight into this topic. Has collusion risk has been discussed previously?

Thanks for this RFC and for sharing your thoughts.  I think you have a lot of good ideas here around additional verification to ensure an immutable blockchain history.  I'd like to add a few comments.  Similar to other blockchains, Libra will have full nodes that verify the history of the chain.  If the validators try to change history, the full nodes will notice and can provide evidence of the attempt to rewrite history.  Full nodes also can re-execute transactions to ensure the correct execution of the transaction history and ensure that the validators are not colluding on arbitrary transaction execution.
Similar to your thinking about anchoring, we have the notion of waypoints (https://github.com/libra/libra/blob/master/tech-papers/lbft-verification/lbft-verification.pdf), an off-chain mechanism for selecting an initial set of validators and and specific point in accumulator history.  It is our hope that these waypoints could be published in trusted sources such as the well known websites as well as embedded in other blockchains as you suggest.
I think that, if it is possible, putting waypoints (or their hashes if they are too big) in other trusted blockchains would be nice service for the community to notify them about any historical forking and build up more trust in the Libra blockchain.

@dmitri-perelman

Agree with @aching about the role of the FullNodes as "external validators".
The idea of anchoring is interesting. As @aching mentioned above, the waypoints are serving a similar purpose. Putting waypoints on a PoW chain could increase trust in the waypoints (today the trust in a waypoint is based on the trust in Libra Association), so it could be a great idea.
@sambarnes as far as I understand your idea, the upload to a PoW could be done externally. An external observer (e.g., a FullNode, or a special Libra Association service) can periodically upload the hash of the latest LedgerInfo / Waypoint to Bitcoin, s.t. Libra chain would know nothing about it.

Thanks for the proposal and for the great discussion.
I totally support the comments already made by @dmitri-perelman and @aching. I would like to emphasize that Libra is a system backed by a reserve and subject to regulation oversight. Hence, the Libra chain is governed by the Libra Association, and the Association has the final authority to determine the state of the chain. This is not like Bitcoin where the users may decide which branch to follow, etc.
@aching and @dmitri-perelman already mentioned Waypoints and Fullnodes. These mechanisms allow the Association to guard and publish the definitive state of the chain.

@aching Huh, interesting! I have not come across waypoints yet while reading, or must have just missed them. I will have to look into that some more. The way you describe them does make it seem like a useful thing to anchor. Likely much more suitable than QCs, at that.
I do agree that full nodes already serve as "external validators" of sorts, and their operators can certainly cry wolf if they notice that a historical re-org happened. However as @dahliamalkhi mentioned, those full node operators have no real power at the end of the day:

... the Libra chain is governed by the Libra Association, and the Association has the final authority to determine the state of the chain. This is not like Bitcoin where the users may decide which branch to follow, etc.

Sure they might have a copy of the old chain-state, but according to who? The Libra Association could (hypothetically) deny that it happened, say it was a bug, and point them towards the real (i.e. newly altered) chain state. The Association could even own up to the historical alteration if the particular instance paints them in a good light with the public. Opening the door for a corrupted organization to control the historical narrative.
Due to regulatory reasons, yes the Association has final say in what the current state of the chain is. Full node operators complaining of historical alterations will just be met with responses of "ehh, too bad". And I'm not saying that is a bad thing, either. Swift and decisive governance is important in a project's growth. After all, the Association has to remain in good standing with nation states if Libra is to succeed globally.
However, the goal of anchoring is not to come to consensus about what the current state of the chain is. The intention is to create an immutable and auditable history of all actions that the Association took to reach that current state (e.g. they progressed along through states A->B->C->D then re-organized to A->B'->C'->D').
I think @dmitri-perelman summarized it perfectly with the following: "Putting waypoints on a PoW chain could increase trust in the waypoints (today the trust in a waypoint is based on the trust in Libra Association)." Its not that this mechanism will allow users to choose a fork to follow (at least not in the near-term centralized stages, while Libra remains a PoA-like protocol). Rather, it will allow users to see a history of the manual changes that were made by the Association, whether such events happen frequently, and if said actions warrant a continuation of trust in them as the governing body.
Perhaps just an opinion: It is the governing body's job to determine the current set of rules that the population abides by. It is not a governing body's job to unilaterally dictate what happened in the past to arrive at that current state. Their actions in breaking promises to their constituents (i.e. reverting "immutable" transactions) should be auditable and well-justified. With an immutable history of said actions, corrupt governance would be more easily exposed, while honest and well-intentioned governance would be rewarded with increased trust. Although all of us here trust the Association to act in good faith, I don't believe that is the case for most people when they see a more centralized blockchain with Facebook origins. It may be wise to proactively encourage trust wherever possible.

@sambarnes as far as I understand your idea, the upload to a PoW could be done externally. An external observer (e.g., a FullNode, or a special Libra Association service) can periodically upload the hash of the latest LedgerInfo / Waypoint to Bitcoin, s.t. Libra chain would know nothing about it.

And yes @dmitri-perelman that's the idea! Any external observer would reserve the ability to submit anchors to Bitcoin, and the Libra chain doesn't need to know. They also reserve the ability to submit the bitcoin receipts back into Libra (e.g. a Move resource or similar) so that others in the ecosystem have an on-chain index of those anchors, instead of needing to parse all of Bitcoin's transactions looking for matching anchors.

@sambarnes, thanks for your response. While the Libra Association does determine the state of the Libra blockchain, I think community run full nodes have an important role of blockchain validation.  For example, hopefully in the future, governments or regulatory bodies could begin running full nodes to validate blockchain updates from the validators.  The Libra Association is subject to regulatory oversight and if regulators discover a violation of the protocol they could coordinate a resolution with the Libra Association.  Additionally, if community operated full nodes expose irregular activity, they could present the evidence to governments or regulatory bodies that could trigger a similar process of resolution.  Finally, if the community found strong evidence of foul play from the validators or the Libra Association via full nodes, they also could simply share the proof publicly and convince the world about the issue - and rightfully question the trustworthiness of the Libra Association.  The existence of these public safeguards (that anyone can verify with a full node) are important to building trust in the Libra Association and its blockchain.
As you suggest, embedding waypoints in other blockchains would be another great way to provide evidence of misbehavior.

@aching while regulatory actions can result in funds reversal, that reversal should, too, be recorded on-chain.  in other words: in no circumstances should history be revised, therefore a community-trusted waypoint seems quite reasonable.


fix endless recursion of normalizer formatter

If the NormalizerFormatter encounters an instance of Traversable it
calls itself on all children of that instance. If the Traversable
returns itself (once, sometimes or always -- doesn't matter) the
formatter goes into endless recursion.
Fix by checking the currently being normalized data to not be
identity-equal to its parent container.

duplicate of  Seldaek/monolog#782?

Theoretically, yes. Technically, I don't know the merge strategy of this project, so I created a PR against 1.x and another one against master.


[JOSS Review] Community guidelines required

Review
JOSS requires that there is a community guidelines section in the documentation.

Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Addressed in dev's ReadMe


Media viewer

Someone made a Nuxt module when the devtools did not exist to view the images in the public directory: https://github.com/cssninjaStudio/nuxt-media-viewer
Here's a preview in the nuxt.com website:
http://volta.s3.fr-par.scw.cloud/Clean_Shot_2023_02_23_at_14_12_17_30d1684814.mp4
The downside is that it extends the Nuxt pages so the implementation in not correct but I do love the idea.
Maybe something we could add with Nuxt Image module?

Do you think we should reuse it (and maybe improve upstream?) or should we implement on ourselves?

I think we shall implement it ourselves but take inspiration from it

The first implementation is in #120
A few TODOs:

[ ] Able to edit plain text content directly
[ ] Drag & Drop to upload
[ ] Tree view for list mode
[ ] Integration with @nuxt/image module (optimize images by one click, etc.)

The first implementation is in #120
A few TODOs:

[ ]  Able to edit plain text content directly
[ ]  Drag & Drop to upload
[ ]  Tree view for list mode
[ ]  Integration with @nuxt/image module (optimize images by one click, etc.)

is something this good for Drag & Drop to upload? for start? video

@arashsheyda You could send a PR and we could discuss it. For me I could like to directly make the panel drop-able, so saving one extra action to open the panel.


can I translate the game using this?

how can I?

No, sorry, I haven't found the texts inside the game.

No, sorry, I haven't found the texts inside the game.

Could it be inside .exe?

Yes, I think they are encrypted inside the .exe file

:( sad thanks for reply


Porting the fixes/hacks from the original IQSS fork

These are the changes from the local fork that were needed to get this thing to work with the Dataverse model of exporting and storing metadata.
I'd like to achieve an intermediate result of being able to build Dataverse from the current develop branch with these new gdcc/xoai libraries and have all the OAI parts work exactly as they are working now, when built with the old jars in local_lib. Before we proceed with any further cleanup and refactoring.
I'll try to explain what these changes do and why that model was chosen.
ref. #2

(I'll fix the failing test tomorrow)

@poikilotherm
This is all based on my best recollection of what we did back in 2016 and why those decisions were made:
We incorporated the basic XOAI implementation framework of managing the sets, records and service verbs. However, we changed quite radically the way the actual metadata content is served. XOAI treats the metadata fragments in the repository as "live" XML. It is parsed; it can be transformed into another format, if needed; and the entire OAI output is written as an XML stream. It was clearly implemented under the assumption that these metadata fragments are fairly small, like a typical DC record; so their Metadata objects have these records fully loaded in memory. The 2 OAI verbs that serve the metadata content, GetRecord and ListRecords, is structured as an outer XML record formatted under OAI's own schema, serving as a wrapper around the dataset metadata proper, with its own schema specified, and its own metadata prefix.
[I'm spelling this out in painful detail under the assumption that somebody who doesn't know much about OAI yet may need to read this as well]
For example, this is the outer wrapper formatting of the GetRecord output:
<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/
         http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>xxx</responseDate>
  <request verb="GetRecord" identifier="..."
           metadataPrefix="oai_dc">https://.../oai</request>
  <GetRecord>
   <record>
    <header>
      <identifier>...</identifier>
      <datestamp>...</datestamp>
      <setSpec>...</setSpec>
      <setSpec>...</setSpec>
    </header>
    <metadata>
      [ ... actual dataset metadata inserted here ... ]
    </metadata>
  </record>
 </GetRecord>
</OAI-PMH>

So a complete output example would look like this:
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/
        http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2022-05-10T17:42:06Z</responseDate>
  <request verb="GetRecord" identifier="doi:10.7910/DVN/QTHFVS"
           metadataPrefix="oai_dc">https://dataverse.harvard.edu/oai</request>
  <GetRecord>
    <record>
    <header>
      <identifier>doi:10.7910/DVN/QTHFVS</identifier>
      <datestamp>2022-05-10T06:08:02Z</datestamp>
      <setSpec>IQSS</setSpec>
    </header>
    <metadata>
      <oai_dc:dc xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
            xmlns:dc="http://purl.org. /dc/elements/1.1/"
            xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/
            http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
        <dc:title>Input parameter file for a global dynamo simulation of Saturn with an SSL</dc:title>
        <dc:identifier>https://doi.org/10.7910/DVN/QTHFVS</dc:identifier>
        <dc:creator>Yadav, Rakesh</dc:creator>
        <dc:publisher>Harvard Dataverse</dc:publisher>
        <dc:description>The data set contains the input parameter file ...</dc:description>
        <dc:subject>Astronomy and Astrophysics</dc:subject>
      </oai_dc:dc>
    </metadata>
  </record>
  </GetRecord>
</OAI-PMH>

(ListRecords is basically the same thing, but for multiple records/datasets)
In the XOAI implementation, in order to produce the record above, we use an XmlWriter to write the service header; then get the oai_dc format record from the repository (let's assume it's already available, no transformations needed), load it in memory in full, parse it and output it; then finish writing the closing elements of the outer service XML.
We made a decision to avoid doing anything potentially resource-expensive inside the Dataverse OAI framework. No metadata transformations would be done in there; meaning, only the datasets for which the metadata in the OAI formats have already been exported and cached would be added to the OAI sets and served as OAI records. We also decided to avoid having to load an entire metadata record into memory at once. Instead the XOAI class would hold onto an InputStream pointing to the cached metadata export, which it would stream directly to the output once the service header part of the OAI response has been written. At that time we were operating under the assumption that Dataverses would continue harvesting FULL DDI records from each other ("full DDI", meaning including the data/variable-level sections; so, for some of our datasets with lots of tabular files, the full DDI exports were running into tens of MBs; too large to keep in memory in full; and definitely impractical to parse on the fly). Most of the modifications that were needed in order to implement these changes were done on the Dataverse side, in the classes overwriting the corresponding XOAI classes. In a couple of cases the hacks above were necessary (such as in the case of needing to expose the private variable, above). At that point we were in a hurry and behind schedule to add harvesting to Dataverse, hence all the questionable choices that were made regarding the quality of the hacks.
It's worth pointing out that we have switched to a model where we only serve the "light DDI" format under OAI, i.e. only the dataset-level metadata without the data sections (the format is called "oai_ddi" in Dataverse; the full format, "ddi" is available for download, but not to OAI clients). These records are much lighter; but can still be quite large. And I still like the idea of keeping the OAI framework super lightweight and relying on the metadata records having already been exported and cached externally. I do of course support the idea of achieving this in a cleaner way.
I hope this makes sense; and I hope my own understanding of it all is correct, after the eons that have passed since those ancient times.

Thank you @landreev for this great explanation on the backgrounds. With this intel, I could dig through the existing Dataverse OAI data provider come with a lot more ease and understand what is going on!
My findings:

You are retrieving the cached metadata from the file storage, saved with the datasets files as auxiliary files (start here)
You are reusing lots of the XOAI classes for headers, the OAIPMH root handle etc., but wrap it in a custom serialization to String and then write these to output stream
You removed the metadata formatting in the GetRecordHandler class within the forked library and removed the same from the ListRecordHandler by cloning the implementation within the Dataverse codebase and adapting as needed.

I'm taking the liberty of proposing a different approach. How about:

Extend the Metadata class to associate Metadata(InputStream) with the stream only - opening, reading and closing it when it's Metadata.write(XmlWriter) time (so not read all into memory)
Refactor the GetRecordHandler and ListRecordHandler not to pass an InputStream from the XSLPipeline but a String (which is cleaner design anyway)
Refactoring our ItemRepository implementation to inject the auxiliary file input stream with the Metadata injected into the Item
Extending the GetRecordHandler and ListRecordsHandler to use Item.getMetadata(), reusing an existing one instead of creating a new Metadata instance when present (which sends things down the pipe, which we don't want).

This should a) avoid building the metadata from scratch everytime and b) avoid reading the metadata files until the very last moment when the writer gets activated.
I propose to discuss this via videoconference - much easier to follow the code pathes and see the things connect.

Closing this one.


(WIP) submit button updates profile. Need to look into warning

After looking at both edit item and edit rating modal, I've made the edit user modal to submit changes upon clicking the submit button, so that works but the current problem is that I'm getting this warning and I need help in figuring out why this is happening.

My understanding is this error happens when a form input value changes from undefined to defined. I wasn't aware of this, but apparently useState is only called on the first component render, and isn't updated if the component re-renders due to a props change: https://stackoverflow.com/questions/54865764/react-usestate-does-not-reload-state-from-props.
What happens is the EditUserModal renders the first time before the AsyncThunk is finished, at which point the props are null, so the form values are all null and stay that way until the form is edited. Then you get the console error.
I guess you're not supposed to use props for default form values. That stackoverflow post says you can use useEffect to update the state when props changes, but maybe there's a better way.

The EditRatingModal is almost similar in that it uses props to pass the initial state into the modal. When you open up the modal, it has default form values. I'm curious as to why it works in the rating modal and not on the profile modal. Looking into it

Think it's because those other modals are deeper in the component tree, so
by the time they're being rendered the data is already fetched.
On Wed., Jul. 20, 2022, 5:07 p.m. nyananu, @.***> wrote:

The EditRatingModal is almost similar in that it uses props to pass the
initial state into the modal. When you open up the modal, it has default
form values. I'm curious as to why it works in the rating modal and not on
the profile modal. Looking into it
—
Reply to this email directly, view it on GitHub
https://github.com/nyananu/somethingBorrowed/pull/80#issuecomment-1190890548,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABS5O5JRV3QX2CUY3X6VBXDVVCICXANCNFSM54B27LKQ
.
You are receiving this because your review was requested.Message ID:
@.***>

The redux state goes away on refresh, so maybe it's the same issue? Profile page loads, it renders the modal, the current User hasn't been fetched and put in the redux store yet, useState sets the values the null, etc.

Works as expected, please review whenever you have a chance.


[APIC-313] retain specific sql types in civis_file_to_table

In the civis.io.civis_file_to_table function, the Python API client appears to tell platform to change SQL types like VARCHAR(1) in the table_columns argument to more generic values like VARCHAR(1024) when there are multiple files.  The behavior seems reasonable when data types are automatically inferred (i.e., when need_table_columns is true), as noted in the code comment, but if the user has specified a dtype with specific length like VARCHAR(1), the import should just use that.

@mheilman looks like the build errored

🤦  sorry about that. Fixed now


Is there supposed to be a delay?

Hi. The chromecast stream hack works great in Windows 10, but there is a about a 3 second DELAY to my old stereo's speakers so if I pause the music, or adjust the volume it will take a few seconds to change on my stereo.  Is there supposed to be a delay, or did i do something wrong?
I turned the volume on my laptop all the way down, so that the music on my laptop doesn't come out of my laptop. And I am adjusting the volume coming through my stereo using the volume control in VLC media player.
PS: I used a a 3.5mm (male) to rca (male) adapter to plug the chromecast into the AUX input on the back of my stereo.

where are the settings for the chromecast buffer? so i can experiment to try to reduce the lag

There's no setting for that, as far as I know.


Raspberry Pi Zero W compatibility issue

Tested on Raspberry Pi Zero W
OS Version: RASPBIAN STRETCH LITE (Release Date: 2018-06-27)
Kernel Version: Linux raspberrypi 4.14.52+ #1123 Wed Jun 27 17:05:32 BST 2018 armv6l GNU/Linux
Go Version: go1.10.3 linux/arm
Problems: I connect to pi via ssh, system freeze after initialize GPIO, but the same code works well on Raspberry Pi 3 which has the same OS Version, Kernel Version and Go Version.
sample code:
const (
	io1    = uint8(5)
	rst    = uint8(13)
	intIn  = uint(26)
	intOut = uint(21)
)
var outPin rpio.Pin
var inPin rpio.Pin
func startGPIO() {
	err := rpio.Open()
	if err != nil {
		log.Fatal(err)
	}
	log.Info("open rpio successfully")
	io1Pin := rpio.Pin(io1)
	io1Pin.Output()
	io1Pin.Low()

	rstPin := rpio.Pin(rst)
	rstPin.Output()
	rstPin.High()

	outPin = rpio.Pin(intOut)
	outPin.Input()
	outPin.Detect(rpio.FallEdge)

	inPin = rpio.Pin(intIn)
	inPin.Output()
	inPin.High()
}

I don't have any Pi Zeros I'm afraid, so not sure what's going on here.
Have you tried different pins? Maybe the mapping is different and 5,13,26 or 21 is used for something critical?
Anyone else using this library with a Pi Zero W here?

Pi Zero W has the same Pin layout with Pi 3B, I try to change pins but still didn't work.
But another library which does GPIO on systems with /sys/class/gpio (sysfs) works on Pi Zero w.
Link: https://github.com/brian-armstrong/gpio

I think the problem may be the getBase func
Sample Code
package main

import (
	"bytes"
	"encoding/binary"
	"fmt"
	"os"
)

func main() {
	fmt.Print(getBase())
}

func getBase() (base int64) {
	ranges, err := os.Open("/proc/device-tree/soc/ranges")
	defer ranges.Close()
	if err != nil {
		return
	}
	b := make([]byte, 4)
	n, err := ranges.ReadAt(b, 4)
	if n != 4 || err != nil {
		return
	}
	buf := bytes.NewReader(b)
	var out uint32
	err = binary.Read(buf, binary.BigEndian, &out)
	if err != nil {
		return
	}
	return int64(out)
}

Result
GOOS=linux GOARCH=arm go build -ldflags "-s -w" -o getBase main.go
sudo ./getBase
[1]    669 illegal hardware instruction  sudo ./getBase

The library failed to open /proc/device-tree/soc/ranges and the error is not properly handled. The RPI.GPIO library also tries to open /proc/device-tree/soc/ranges, but use hard coded base if error occured
Sample Code ( from c_gpio.c setup func )
#define BCM2708_PERI_BASE_DEFAULT   0x20000000
#define BCM2709_PERI_BASE_DEFAULT   0x3f000000

// determine peri_base
    if ((fp = fopen("rranges", "rb")) != NULL) {
        // get peri base from device tree
        fseek(fp, 4, SEEK_SET);
        if (fread(buf, 1, sizeof buf, fp) == sizeof buf) {
            peri_base = buf[0] << 24 | buf[1] << 16 | buf[2] << 8 | buf[3] << 0;
        }
        fclose(fp);
    } else {
        // guess peri base based on /proc/cpuinfo hardware field
        if ((fp = fopen("/proc/cpuinfo", "r")) == NULL)
            return SETUP_CPUINFO_FAIL;

        while(!feof(fp) && !found) {
            fgets(buffer, sizeof(buffer), fp);
            sscanf(buffer, "Hardware	: %s", hardware);
            if (strcmp(hardware, "BCM2708") == 0 || strcmp(hardware, "BCM2835") == 0) {
                // pi 1 hardware
                peri_base = BCM2708_PERI_BASE_DEFAULT;
                found = 1;
            } else if (strcmp(hardware, "BCM2709") == 0 || strcmp(hardware, "BCM2836") == 0) {
                // pi 2 hardware
                peri_base = BCM2709_PERI_BASE_DEFAULT;
                found = 1;
            }
        }
        fclose(fp);
        if (!found)
            return SETUP_NOT_RPI_FAIL;
    }

I can confirm this issue with Raspberry Pi Zero W.
My Pi freezes after pin.Detect().

It works fine with my Pi Zero W, but I have a different environment.
OS:  Raspbian GNU/Linux 8.0 (jessie)
Kernel:  Linux zero 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
Go: go1.8.3 linux/arm

@mikumaycry You might hit the nail on the head with the getBase.
Think is go-rpio always fallback to hardcoded adress 0x20000000 (BCM2835)
Rpi Zero probably uses  0x3f000000 (BCM2836). Hence it does not work.
I can make fix inspired by the code you posted. But I still see BCM2835 in output of  cat /cpu/info, instead of BCM2836, how is that?
Anyway, the real question is why the file /proc/device-tree/soc/ranges can not be opened.

@mikumaycry BTW, you forgot the fallback line https://github.com/stianeikeland/go-rpio/blob/master/rpio.go#L628 in your sample code.

@Drahoslav7
BCM2835 has default GPIO base and it won't use 0x3f000000. Details can be found here:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf
@stianeikeland
But I think I've located the problem.
The default GOARM is 7 on macOS, the same as Raspberry Pi 2, 3. But default GOARM is 6 on Raspberry Pi A, A+, B, B+, Zero.
Before I upgrade RPi Zero kernel to latest, it's almost impossible to compile code on it, the go build command usually never stops.
I cross compile on mac and then copy executable file to RPi Zero, so the programs stuck due to wrong GOARM.
I just recompiled sample code on RPi Zero and it successfully open /proc/device-tree/soc/ranges and return.

Goodie! So if you try using GOARM=6 on your mac, it works?
If that's the case, we should probably make a note of it in the readme.md


🐛 Fix nil-ptr access bug

Please check if the PR fulfills these requirements

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] PR title follows the guidelines defined in  https://github.com/ossf/scorecard/blob/main/CONTRIBUTING.md#pr-process

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Nil-ptr access bug.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No.

@azeemshaikh38 Thanks for taking care of this. And good idea to make the helper functions to do the nil checking in.


How can I refresh the files/directories?

- [X ] Vim

OS

[ X] Linux

Shell

[X ] bash

Simple question- sometimes fzf doesn't pick up newly created files. Is there a shortcut to refresh fzf's view of the filesystem?

sometimes fzf doesn't pick up newly created files

Maybe you created a new buffer and didn't save it to disk? fzf is an external process so it cannot see files that are not persisted on disk.
It depends on the source command used, but by default fzf always scans the file system.
Please read https://github.com/junegunn/fzf#usage

Same issue. I can bring up the file with :e command but not :GFiles. This is on a mac with zsh.


Duplicated imports "useSeoMeta", the one from "#head" has been ignored

Describe the bug
I have upgraded to nuxt v3.1.0 and now I get that warning in the console.

Reproduction
No response
System Info
System:
    OS: Windows 10 10.0.22621
    CPU: (4) x64 AMD Ryzen 3 3200G with Radeon Vega Graphics
    Memory: 5.82 GB / 13.94 GB
  Binaries:
    Node: 19.3.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 3.3.0 - C:\Program Files\nodejs\yarn.CMD
    npm: 9.2.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22621.1105.0), Chromium (108.0.1462.76)
    Internet Explorer: 11.0.22621.1

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

Hi, please upgrade to 1.0.1 :)


Week of 3/20

Aadit Gupta

[ ] Peer Grade and Review (Required), Reviews will be done in Pairs-Trios
[x] Perform Hacks

Queue to Stack, Add/Delete Elements from Queue
Merge Ordered Queues
Sorting Algorithms
Stack T hack Merging

[x] PBL Work

Started database storing for FRQ Data
Working on setting up Judge0 for class
Working on Frontend API with judge with Daniel
Will be integrated Judge0 ide with judge0 API for code editing and submitting.

[x]  Github Commits

Score: 2.9/3

Great job, did everything plus some more

Task
Grade
Comment

Peer Grade
1/1
Peer graded Krish

Hacks
1/1
Hacks are all running, compiles well

Build Stack
1/1
Stack built

Github Commits
1/1
Contributions are sufficient for the month


Adding ARCHIVE DESTINATION to fix CMake error

Thanks for the PR! Interesting. In Zydis, we have this:
install(TARGETS "Zydis"
    EXPORT "zydis-targets"
    ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})

I think we should probably also add LIBRARY DESTINATION here for consistency. I suspect that things will otherwise break under these CMake versions if a shared library is built. No need for RUNTIME DESTINATION though -- Zycore doesn't have any binaries and I don't expect it to ever gain any.

Good idea-- added that, too.

Leaving this for future reference: in CMake 3.14, these various <TYPE> DESTINATION <DIRECTORY> fields are implied by default, so they can be removed to make the code a bit cleaner :)


saving best model

Hi Yassine,
During training, is always the latest model saved or only the best?
If the best model is saved, on which metric is that decision based?
For example: This is what I got after 76 epochs

but at 78 the model stopped and its mIoU for the EVAL set is lower:

Hi @SuzannaLin the best model is saved based on mIoU, this is specified in the config file "monitor": "max Mean_IoU"

Thanks for your answer!


feat(strm-1433): implement invite users command

:tada: This PR is included in version 2.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Literal types are not supported

The case:
   interface Test {prop: {field: string}}
   const result = Forger.create<Test>()!;

Actual result: false. The object is not created properly.
Expected result: Something like { prop: { field: 'ZPyXa#V_%5' } }

Fixed at v. 1.0.9


x/pkgsite: make import paths in Examples into links

What is the URL of the page with the issue?
https://pkg.go.dev/gonum.org/v1/gonum/graph/encoding/dot
What is your user agent?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
Screenshot

What did you do?

I clicked "gonum.org/v1/gonum/graph/simple"
What did you expect to see?
Browser opens https://pkg.go.dev/gonum.org/v1/gonum/graph/simple
What did you see instead?
Nothing. It's plain text. 😞

The playground widget would need to be updated for this.
One tricky bit here is that <textarea> elements don't let you
put clickable links in them, so the widget would have to be
rewritten to support it.


MultiProcessingReadingService: Shuffle / combine batches from workers

🚀 The feature
I would like to make the use of MultiProcessingReadingService as opaque as possible. In particular, it should not affect the shuffling behavior. For that, I need more control and be able to manually expand the internal pipeline of the MultiProcessingReadingService AFTER worker batches are received in a round-robin fashion such that I could e.g. add an additonional shuffle buffer. It would be good to have an extension point for this. Potentially, the Adapter protocol could be expanded for this.
Also, on a side note: There should possibly be an Adapter that divides the shuffle buffer size of shuffle operations, so that the overall memory consumption does not depend on the amount of IO workers. The existing Shuffle adapter could be expanded for this. While I am aware that the documentation recommends placing shuffling operations as early as possibly where they still might act on a logical level, there can be situations where this is simply not possible and shuffling has to be done at the end.
Motivation, pitch
I'm working with horovod which spawns one MPI process per GPU on each node. Logical sharding of the dataset takes place in this MPI setting and usage of the MultiProcessingReadingService (per process/gpu/shard) should be seen as an implementation detail. As such, I don't want it to affect the shuffling behavior within a shard, i.e. there should be no difference in randomness between training with 1 IO worker or training with 8 IO workers per GPU.
In my particular case, shuffling also needs to be performed right at the end of the pipeline.
Alternatives
No response
Additional context
No response

In particular, I would like to be able to do
end_datapipe = self._worker_consumer_datapipe.unbatch().shuffle(n_workers*batchsize).batch(batchsize)

immediately after https://github.com/pytorch/data/blob/main/torchdata/dataloader2/reading_service.py#L297
Since I'm not that familiar with the codebase you probably have a better approach, but something along the lines of a Adapter.finalize_main_pipeline() and a Adapter.finalize_worker_pipeline() function would be a good solution for this IMO.
This would also allow us to implement the main process and worker process prefetchs as Adapters which then can be reused with other ReadingServices as well and would be more in-line with the existing design IMO.

There is a way to achieve that without relying on Adapter. When you define your pipeline, you can specify the DataPipe that you want to keep in the main process by attaching a method of is_replicable() and returning False. Then, MPRS would launch workers with the replicable eDataPipe graph prior to this non-replicable DataPipe and re-connect the "end_datapipe` to the non-replicable DataPipe

@ejguan That's some great news! Is it possible to wrap a sub-graph into a DataPipe (this is some question I had anyways), so that I could reuse the already existing implementations? I.e. specifically I would need to wrap .unbatch().shuffle(n_workers*batchsize).batch(batchsize) into a new DataPipe (class) and then implement is_replicable() to return false.

Also, on a side note: I think it would be good to highlight this option in the documentation. Disregard this comment if that is already the case and I just overread it.

Is it possible to wrap a sub-graph into a DataPipe (this is some question I had anyways), so that I could reuse the already existing implementations?

Technical speaking, yes you can. But, in the traverse_dps function, we will treat them as separate DataPipes rather than a single one.

I.e. specifically I would need to wrap .unbatch().shuffle(n_workers*batchsize).batch(batchsize) into a new DataPipe (class) and then implement is_replicable() to return false.

I should clarify a little bit. The MultiProcessingReadingService will go through the DataPipe graph and find the first non-replicable DataPipe, and keep this DataPipe with subsequent DataPipes in the main process, by that I mean you only need to add is_replicable() function to unbatch.

@ejguan Great, thanks a lot!
Some additional thoughts on this:

Adding a single non-replicable pipe seems to be fine for now, as the MPRS only supports a single replicable branch anyways as of now.
This might not hold in the future (multiple replicable branches  would actually be a cool feature!), and thus a proper wrapping pipe would become necessary. I think something along the lines of  a "SynchronizerPipe(*pipes)" should become part of the standard API; where *pipes denotes a part of the graph that should we non-replicable.

If I understood you correctly wrt. composability the canonical way would look something like this?
class ComposedPipe(dp.iter.IterDataPipe):
    def __init__(datapipe):
          self.datapipe =  datapipe.map(lambda x: x).unbatch() #etc
     def __iter__(self):
           for x in self.datapipe:
                  yield x + 42

And as such, traverse_dps picks this up as 3 pipes. Ideally, there should be a way in the future that allows us to hide this from the outside world. I.e. ComposedPipe should appear as a single pipe in the graph, since the sub-pipes are an implementation detail (code reuse). Adding pipes after our own implementation is also a bit contrived, since we would need a separate iterator object, pass that object to the "suffix" pipe, and finally in __iter__ return the iterator of the suffix pipe.
If you want, you can close this issue :)

This might not hold in the future (multiple replicable branches  would actually be a cool feature!), and thus a proper wrapping pipe would become necessary.

Yeah. That's something in my mind as well. But, I might do it in a separate ReadingService as it requires more complicated arguments to set number of workers per replicable branch.

I think something along the lines of  a "SynchronizerPipe(*pipes)" should become part of the standard API; where *pipes denotes a part of the graph that should we non-replicable.

Could you please elaborate it? I do not fully understand. As a reference, we do have zip DataPipe to combine multiple DataPipes.

If I understood you correctly wrt. composability the canonical way would look something like this?

Yeah. Just want to callout that lambda function is not recommended in TorchData as it's non-picklable.

And as such, traverse_dps picks this up as 3 pipes. Ideally, there should be a way in the future that allows us to hide this from the outside world. I.e. ComposedPipe should appear as a single pipe in the graph, since the sub-pipes are an implementation detail (code reuse). Adding pipes after our own implementation is also a bit contrived, since we would need a separate iterator object, pass that object to the "suffix" pipe, and finally in __iter__ return the iterator of the suffix pipe.

I am not convinced for a few reasons:

We rely on attribute to build up a graph. For the ComposedPipe, even if we hide some inner DataPipe, we still need to reference to the source DataPipe. Then, branching happens in ComposedPipe, as it references to source DataPipe and the hidden DataPipe that will nested reference to the same source DataPipe
Sub-pipes might be implementation detail, but DataLoader2 and ReadingService might need to run some magic methods (e.g. checkpointing) to every single DataPipe in the graph. By hiding those DataPipes from the grpah, it becomes hard to do so at least for now.

Technically speaking, I would hope users don't need to do anything with traverse_dps by themselves. TorchData should provide all utility graph functions. So, I guess I would dive deeper on this if any user reports their use causes.

If you want, you can close this issue :)

Do you mind updating the summary of Issue to update the document to keep non-replicable DataPipe in the main process for MPRS? Then, we don't need to close this Issue.
Thank you!


Linux AppImage | Arch with X11 seg faults

As reported in:

https://github.com/mu-editor/mu/issues/2331#issuecomment-1218262926
https://github.com/mu-editor/mu/issues/2295#issuecomment-1216821125

No settings file found at /home/myself/.local/share/mu/venv.json; skipping
fish: Job 1, './Mu_Editor-1.1.1-x86_64.AppIma…' terminated by signal SIGSEGV (Address boundary error)

dmesg:
[140410.054283] python3.8[134164]: segfault at 52b9 ip 00007f3913ee5ed8 sp 00007fff723f8fa0 error 4 in libX11.so.6.4.0[7f3913ed9000+8b000]
[140410.054290] Code: e8 bd f8 ff ff 48 8b 9d 48 12 00 00 48 85 db 74 29 ff 15 cb 5b 11 00 eb 11 66 0f 1f 84 00 00 00 00 00 48 8b 1b 48 85 db 74 10 <48> 39 43 08 75 f2 48 83 c4 08 5b 5d c3 0f 1f 00 48 8b 85 30 0a 00
[140410.054432] audit: type=1701 audit(1657982545.600:1232): auid=1000 uid=1000 gid=1000 ses=11 pid=134164 comm="python3.8" exe="/tmp/.mount_Mu_EdixuOhZu/usr/bin/python3.8" sig=11 res=1
[140410.057756] audit: type=1334 audit(1657982545.603:1233): prog-id=136 op=LOAD
[140410.057821] audit: type=1334 audit(1657982545.603:1234): prog-id=137 op=LOAD
[140410.057824] audit: type=1334 audit(1657982545.603:1235): prog-id=138 op=LOAD
[140410.058588] audit: type=1130 audit(1657982545.606:1236): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@21-134173-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[140410.278299] audit: type=1131 audit(1657982545.823:1237): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@21-134173-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[140410.415272] audit: type=1334 audit(1657982545.963:1238): prog-id=0 op=UNLOAD
[140410.415283] audit: type=1334 audit(1657982545.963:1239): prog-id=0 op=UNLOAD
[140410.415287] audit: type=1334 audit(1657982545.963:1240): prog-id=0 op=UNLOAD

It does work when using Wayland in Arch Linux.

Hi carlosperate,
To answer to Your post in this  issue https://github.com/mu-editor/mu/issues/2331#issuecomment-1316916799 (unfortunately issue has been closed unsolved)
Your created mu-editor AppImage (Mu_Editor-1.2.0-x86_64.AppImage) runs on Manjaro (Arch based) while the official MuEditor-Linux-1.2.0-x86_64.AppImage does not. Segmentation fault. libxcrypt-compat is installed.
Rgds
https://github.com/mu-editor/mu/issues/2331#issuecomment-1316916799


how to disable sass warnings?

Category

[x] Question
[ ] Typo
[ ] Bug
[ ] Additional article idea

I would like to disable sass workings as follows as I don't use module.scss on some classes.
Warning - [sass] src/webparts/HelloWorld/tabs.scss: filename should end with module.scss
And I found that there isn't any option to do so. Any ideas?

Drop a line in your gulpfile.js that says:
build.addSuppression(`Warning - [sass] src/webparts/HelloWorld/tabs.scss: filename should end with module.scss`);

See documentation here.
However, we strongly recommend you use module.scss instead of vanilla scss to ensure your styles don't conflict with other styles on the page. Is there a reason why you can't convert your styles to module.scss?

Thanks @iclanton.
Mainly because currently I have to maintain 2 separate project (on prem and spfx). And my on prem tooling isn't supporting module.css (which I still figure out how). My aim is to have same codebase that works on both project with minimal code modification.
https://github.com/jonathanhotono/typescript-react-sass
I am also not sure whether it's possible to integrate gulp-core-build with my on prem project. And whether gulp-core-build-sass will provide me with the sourceMap access so I can have my scss files displayed correctly in chrome devtools which I have raised a separate issue a few month back #479


Launching the demo is convoluted

The full documentation is spread across multiple sub-directories and can not be located in a particular order. Additionally some necessary documentation is missing. Combine this with all of the pieces that need to be installed locally, which can cause compatibility issues, makes the demo very difficult to get running.

#7


SSL cert ACLs

Can you clarify the statement:
Need to also make sure certificate has proper ACL to be retrieved by YarpProxy process running under the configured local account (by default SF applications run under Network Service account) so that the private key can be accessed during the SNI step in TLS handshake.
How exactly do you do that?  I don't have any control over the nodes, certs are installed in the scaleset by ARM..
Getting:  "Yarp.ServiceFabric.Core.Service.Security.ServerCertificateBinding.SniServerCertificateSelector[0]
Encountered error when tried to validate private key access for certificate with subject name....."

I found this: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-best-practices-security#apply-an-access-control-list-acl-to-your-certificate-for-your-service-fabric-cluster

https://github.com/Azure/Service-Fabric-Troubleshooting-Guides/blob/master/Security/Set ACL for a SF certificate.md
Following this, I added a script, and a custom extension to run it.  I can confirm that it does modify the private key ACL and add NETWORK SERVICE.  I'll submit a PR to the https://github.com/Azure/Service-Fabric-Troubleshooting-Guides repo with the script and ARM extension sample.


Extra ignore does not seems to work on my case

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
I try to migrate my code to Pydantic V2 and I encounter an issue that I don't know how to solve. It seems that I miss something.
I have a function that build multiple models from a json data.
def build_models(self, raw_extracted_data: dict)
        # others pydantic model
        # .....
        self.document: Document = Document(**raw_extracted_data)

It may be possible that on the raw_extracted_data  data, it miss some data.
I was able to make it work using the extra = Extra.ignore
So on the data, I don't have the appropriate key and everything was ignored.
class Document(BaseModel):
    civil_info: CivilInfo | None
    income: IncomeDetails | None

    @root_validator(pre=True)
    def extract_document(cls, values):
        automatic_bill_document = values.get("automatic_bill_document")
        if automatic_bill_document is not None:
            return automatic_bill_document
        return values

    class Config:
        extra = Extra.ignore

Now after migrating to V2 I did the following
class Document(BaseModel):
    model_config = ConfigDict(extra='ignore')

    civil_info: CivilInfo | None
    income: IncomeDetails | None

    @model_validator(mode="before")
    def extract_document(cls, values):
        automatic_bill_document = values.get("automatic_bill_document")
        if automatic_bill_document is not None:
            return automatic_bill_document
        return values

and I got this kind of validation errors
    self.__pydantic_validator__.validate_python(data, self_instance=self)
pydantic_core._pydantic_core.ValidationError: 2 validation errors for Document
civil_info
  Field required [type=missing, input_value={'test_d...00,21', 'rate': '10'}}}}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.7/v/missing
income
  Field required [type=missing, input_value={'test_d...00,21', 'rate': '10'}}}}, input_type=dict]
    For further information visit https://errors.pydantic.dev/2.7/v/missing

If I set my attributes civil_info: CivilInfo | None = None and income: IncomeDetails | None = None, I have validations errors for others fields above. I cannot write everything optional.
Any insights ? Thank you.
Example Code
No response
Python, Pydantic & OS Version
python3 -c "import pydantic.version; print(pydantic.version.version_info())"
             pydantic version: 2.7.3
        pydantic-core version: 2.18.4
          pydantic-core build: profile=release pgo=true
                 install path: /Users/Documents/dev/doc-extractor/.venv/lib/python3.11/site-packages/pydantic
               python version: 3.11.2 (main, Feb 24 2023, 14:47:46) [Clang 14.0.0 (clang-14<IP_ADDRESS>)]
                     platform: macOS-14.4.1-arm64-arm-64bit
             related packages: mypy-1.10.0 typing_extensions-4.12.1
                       commit: unknown

@lironesamoun,
Thanks for your question. I believe this is the expected behavior. We wrote a section on how optional fields changed in V2, which you can find here: https://docs.pydantic.dev/latest/migration/#required-optional-and-nullable-fields.
Let me know if you have any other questions - please submit an executable code snippet (minimal reproducible example) with imports, etc!


js-reps

I will get to it as soon as I complete the calculator
Sent from my iPhone
On Mar 26, 2018, at 11:22 AM, Reuben Ayres <notifications<EMAIL_ADDRESS>wrote:
@reubenayres commented on this pull request.

In JS/functions.jshttps://github.com/ga-chicago/js-reps/pull/13#discussion_r177152504:

+const toonify = (accent,sentence)=>{

  if(accent === "daffy"){

          let newSentence = sentence.replace(/s/g,"th");

          return newSentence;

  }

  else if(accent === "elmer"){

          let newSentence = sentence.replace(/r/g,"w");

          return newSentence;

  }

  else{

          return sentence;

  }

+}
+
+console.log(toonify('elmer','I love rock and roll'));
+
where are the rest of the questions? please finish the rest of the questions listed here: https://github.com/ga-chicago/js-reps and submit as a separate repo
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/ga-chicago/js-reps/pull/13#pullrequestreview-106976373, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYopExozXBcxm1Ct3pACWK5Yc-pxdJpiks5tiRW5gaJpZM4St2uq.


Subscribe page back link always links to home page

The default subscriber page "back" link always links to the home page. I would expect it to link to the page the user was on before they clicked on the "subscribe" link.

Ghost Version: 0.9.0beta1
Node Version: v4.4.0
Browser/OS: Linux/Firefox
Database: MySQL

Thanks @jonblack
I can confirm this behaviour.

<a<EMAIL_ADDRESS>class="gh-flow-back"> Back seems to be pretty static :)
@kirrg001: not sure if this is a valid solution, but one could simply use onclick="javascript:history.go(-1)".  This will work in most cases.
When accessing https://url/subscribe/ directly this will lead to a blank page (imo unimportant edge case).
When being referred from somewhere else this will direct to the referrers page (don't know if this is the wanted behavior - even if it does what "back" says).
If javascript is disabled it will fall back to the current behavior.
If you want me to, I can do a pr with the described solution.

Ups, sry for the spam... first used javascript:history.go(-1) and then read, that this has some problems in older chrome versions and window.history.go(-1) is the official way to go.

I think I see where the problem might be although I haven't tested it yet. This line will the grab the value of the .referrer input and put it back into that input, there's a conditional there which is intended to fall back to document.referrer but it will never be reached as an empty string (which is why you'll get back from that selector) is truthy. I'm assuming the tests fake it by passing in null rather than an empty string which is why they are passing.


Embedded locksmith does not work with etcd 3.5 or 3.4

Description
When using Flatcar LTS (or possibly other channels, as the etcd go client in locksmith repository was not updated for years), the locksmith is unable to connect to etcd instance that runs version 3.4 or 3.5 (only these are currently supported from security perspective: https://endoflife.date/etcd ). I was able to make it work with version 3.0, but I don't like running obsolete etcd in production environment.
Impact
Unable to run secure etcd server in production as locksmith etcd client does not support current version of etcd (3.4 or 3.5).
Environment and steps to reproduce
Have Flatcar machine with private IP <IP_ADDRESS> provisioned with Flacar LTS-2024.
Run local etcd instance and use this instance for locksmith reboot strategy, e.g. using Butane config (transpile with ct):
etcd:
  version:                     3.5.13
  # version:                     3.4.32
  name:                        s1
  advertise_client_urls:       http://<IP_ADDRESS>:2379
  initial_advertise_peer_urls: http://<IP_ADDRESS>:2380
  listen_client_urls:          http://<IP_ADDRESS>:2379
  listen_peer_urls:            http://<IP_ADDRESS>:2380
  initial_cluster:             s1=http://<IP_ADDRESS>:2380

update:
  group: lts-2024
  server: https://public.update.flatcar-linux.net/v1/update/

locksmith:
  reboot_strategy: etcd-lock
  window_start:    Sun 4:00
  window_length:   2h
  etcd_endpoints:  http://<IP_ADDRESS>:2379
  group:           common

Expected behavior
locksmithd.service should run without any errors. locksmithctl should be able to display status.
Additional information
Actual behavior:
> systemctl status locksmithd.service
...
May 06 13:32:55 vultr.guest locksmithd[1156]: Unlocking old locks failed: error setting up lock: Error initializing etcd client: creating etcd lock client: client: response is invalid json. The endpoint is probably not valid etcd cluster endpoint. Retrying in 20s.

> locksmithctl --endpoint=http://<IP_ADDRESS>:2379 status
Error initializing etcd client: creating etcd lock client: client: response is invalid json. The endpoint is probably not valid etcd cluster endpoint

The etcd2 protocol is needed, you need to configure it with --enable-v2.
For v3 support we have an existing issue: https://github.com/flatcar/Flatcar/issues/510#issuecomment-2068633026

Thank you, I was looking for this option but couldn't find it.
I was able to make it work with the compatibility flag.
If somebody else needs this, here is the working setup for etcd:
etcd:
  version:                     3.5.13
  enable_v2:                   true
  name:                        s1
  advertise_client_urls:       http://<IP_ADDRESS>:2379
  initial_advertise_peer_urls: http://<IP_ADDRESS>:2380
  listen_client_urls:          http://<IP_ADDRESS>:2379
  listen_peer_urls:            http://<IP_ADDRESS>:2380
  initial_cluster:             s1=http://<IP_ADDRESS>:2380

Also note that this option is already deprecated in 3.5 and will be dropped in etcd 3.6.


[UI]: Add storage managment

Is your feature request related to a problem?
Currently, there is no consistent way to save sessions other than using local storage, which cannot be easily managed. The IStorage interface is only available when using the SDK, not the UI package.
Describe the solution you'd like
Ideally, there should be an IStorage interface implemented in the @tonconnect/ui package, providing an alternative way to save sessions, rather than relying solely on browser local storage.
Describe alternatives you've considered
As an alternative, it's possible to manually read and save these local storage keys on the backend when the wallet is connected:
ton-connect-storage_bridge-connection
ton-connect-ui_last-selected-wallet-info
ton-connect-storage_http-bridge-gateway::https://bridge.ton.space/bridge
ton-connect-ui_wallet-info
ton-connect-ui_preferred-wallet

Afterward, we can manually set these keys with the values retrieved from the backend, overriding the values set by the UI package, which is not reliable.
Additional context
No response

it would be nice

Yes, it is needed.

You should be able provide your own storage:
https://github.com/ton-connect/sdk/tree/main/packages/sdk#init-connector


tools: add a benchmark tool for hearbeat

Signed-off-by: nolouch<EMAIL_ADDRESS>
What problem does this PR solve?
To benchmark the performance of handing heartbeat.
What is changed and how it works?
example:
❯ ./heartbeat-bench
ClusterID:<PHONE_NUMBER>986197874
bootstrapped
finish put stores

--------- Bench heartbeat (Round 1) ----------
store 1 finish heartbeat, cost time: 42.580442683s
store 9 finish heartbeat, cost time: 42.620485179s
store 19 finish heartbeat, cost time: 42.863172835s
store 18 finish heartbeat, cost time: 43.035728396s
store 20 finish heartbeat, cost time: 43.0527188s
store 6 finish heartbeat, cost time: 43.059825617s
store 10 finish heartbeat, cost time: 43.112139272s
store 13 finish heartbeat, cost time: 43.115090363s
store 3 finish heartbeat, cost time: 43.11638077s
store 5 finish heartbeat, cost time: 43.120537883s
store 12 finish heartbeat, cost time: 43.132455427s
store 16 finish heartbeat, cost time: 43.13932419s
store 14 finish heartbeat, cost time: 43.147619339s
store 4 finish heartbeat, cost time: 43.151354573s
store 2 finish heartbeat, cost time: 43.160081243s
store 8 finish heartbeat, cost time: 43.263776622s
store 7 finish heartbeat, cost time: 43.275595781s
store 11 finish heartbeat, cost time: 43.371469709s
store 15 finish heartbeat, cost time: 43.409647719s
store 17 finish heartbeat, cost time: 43.673221641s

Summary:
  Total:	43.6778 secs.
  Slowest:	0.8482 secs.
  Fastest:	0.0000 secs.
  Average:	0.0009 secs.
  Stddev:	0.0094 secs.
  Requests/sec:	22895.3795

Response time histogram:
  0.0000 [1]	|
  0.0848 [996730]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.1696 [3023]	|
  0.2545 [223]	|
  0.3393 [21]	|
  0.4241 [2]	|
  0.5089 [0]	|
  0.5937 [0]	|
  0.6786 [0]	|
  0.7634 [19]	|
  0.8482 [1]	|

Latency distribution:
  10% in 0.0000 secs.
  25% in 0.0000 secs.
  50% in 0.0000 secs.
  75% in 0.0000 secs.
  90% in 0.0000 secs.
  95% in 0.0000 secs.
  99% in 0.0006 secs.
  99.9% in 0.1058 secs.

Sample in one second (unix latency throughput):
UNIX-SECOND,MIN-LATENCY-MS,AVG-LATENCY-MS,MAX-LATENCY-MS,AVG-THROUGHPUT
1571327127,788ns,323.642µs,106.739947ms,25544
1571327128,781ns,747.551µs,130.067004ms,27126
1571327129,782ns,748.791µs,150.723973ms,26414
1571327130,784ns,776.141µs,143.202947ms,25636
1571327131,783ns,815.447µs,174.68032ms,24621
1571327132,778ns,853.462µs,142.031431ms,23793
1571327133,779ns,760.395µs,141.936154ms,25882
1571327134,784ns,798.214µs,162.616604ms,25009
1571327135,792ns,878.417µs,230.237056ms,23017
1571327136,781ns,866.963µs,184.986608ms,22656
1571327137,782ns,716.423µs,118.479538ms,28183
1571327138,775ns,980.729µs,268.449372ms,20249
1571327139,782ns,760.776µs,134.315416ms,26076
1571327140,786ns,932.908µs,299.566858ms,21413
1571327141,777ns,758.951µs,126.164672ms,26464
1571327142,775ns,863.657µs,152.634238ms,23502
1571327143,781ns,1.017866ms,231.457625ms,19473
1571327144,782ns,796.898µs,133.192405ms,25151
1571327145,782ns,1.072382ms,278.954867ms,19667
1571327146,780ns,796.124µs,155.28796ms,23529
1571327147,782ns,849.546µs,151.18481ms,23326
1571327148,779ns,801.438µs,139.823777ms,24815
1571327149,772ns,1.279535ms,291.934335ms,15683
1571327150,784ns,871.513µs,181.738208ms,23114
1571327151,778ns,938.72µs,158.016393ms,21316
1571327152,777ns,748.131µs,141.335129ms,26658
1571327153,784ns,1.262454ms,393.043323ms,15586
1571327154,778ns,723.609µs,140.224914ms,27628
1571327155,776ns,870.738µs,147.559517ms,23308
1571327156,781ns,780.453µs,136.00597ms,25151
1571327157,782ns,821.709µs,142.437387ms,24603
1571327158,785ns,1.57976ms,355.690413ms,12448
1571327159,774ns,848.865µs,186.433177ms,23890
1571327160,786ns,927.24µs,162.513711ms,21510
1571327161,779ns,759.99µs,135.826571ms,26173
1571327162,778ns,762.124µs,128.748933ms,26173
1571327163,782ns,1.236054ms,848.211744ms,20734
1571327164,804ns,2.772501ms,746.674495ms,5387
1571327165,782ns,921.272µs,191.09674ms,21025
1571327166,778ns,814.464µs,142.33664ms,24524
1571327167,770ns,814.118µs,137.200021ms,24569
1571327168,781ns,907.881µs,143.304291ms,22092
1571327169,772ns,862.67µs,145.800969ms,22823
1571327170,779ns,945.935µs,152.286216ms,13933
1571327171,828ns,1.557664ms,227.092562ms,146

--------- Bench heartbeat (Round 2) ----------
store 1 finish heartbeat, cost time: 7.637462195s
store 19 finish heartbeat, cost time: 7.899849567s
store 18 finish heartbeat, cost time: 7.936266795s
store 4 finish heartbeat, cost time: 8.027330119s
store 10 finish heartbeat, cost time: 8.064582617s
store 9 finish heartbeat, cost time: 8.092133678s
store 17 finish heartbeat, cost time: 8.212758254s
store 5 finish heartbeat, cost time: 8.245043888s
store 20 finish heartbeat, cost time: 8.719631093s
store 7 finish heartbeat, cost time: 8.962240003s
store 13 finish heartbeat, cost time: 9.09039731s
store 6 finish heartbeat, cost time: 9.29339005s
store 2 finish heartbeat, cost time: 9.353499612s
store 16 finish heartbeat, cost time: 9.480885412s
store 12 finish heartbeat, cost time: 9.598450296s
store 8 finish heartbeat, cost time: 9.739297485s
store 3 finish heartbeat, cost time: 9.784913961s
store 14 finish heartbeat, cost time: 9.785700283s
store 11 finish heartbeat, cost time: 9.793207832s
store 15 finish heartbeat, cost time: 9.794701415s

Summary:
  Total:	9.7948 secs.
  Slowest:	0.6721 secs.
  Fastest:	0.0000 secs.
  Average:	0.0002 secs.
  Stddev:	0.0057 secs.
  Requests/sec:<PHONE_NUMBER>

Response time histogram:
  0.0000 [1]	|
  0.0672 [999313]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.1344 [339]	|
  0.2016 [187]	|
  0.2688 [72]	|
  0.3361 [41]	|
  0.4033 [18]	|
  0.4705 [19]	|
  0.5377 [15]	|
  0.6049 [13]	|
  0.6721 [2]	|

Latency distribution:
  10% in 0.0000 secs.
  25% in 0.0000 secs.
  50% in 0.0000 secs.
  75% in 0.0000 secs.
  90% in 0.0000 secs.
  95% in 0.0000 secs.
  99% in 0.0000 secs.
  99.9% in 0.0329 secs.

Sample in one second (unix latency throughput):
UNIX-SECOND,MIN-LATENCY-MS,AVG-LATENCY-MS,MAX-LATENCY-MS,AVG-THROUGHPUT
1571327171,1.351µs,905.779µs,519.767383ms,14199
1571327172,805ns,1.497563ms,415.098309ms,11894
1571327173,796ns,1.454812ms,293.169369ms,14883
1571327174,828ns,3.321515ms,612.172878ms,6021
1571327175,802ns,2.639892ms,672.108266ms,8207
1571327176,789ns,175.226µs,339.219364ms,86945
1571327177,797ns,76.435µs,365.673545ms,256367
1571327178,845ns,139.559µs,359.332802ms,129828
1571327179,803ns,39.214µs,112.681827ms,375571
1571327180,1.013µs,130.202µs,109.811237ms,74195
1571327181,950ns,64.677µs,39.676263ms,21910

--------- Bench heartbeat (Round 3) ----------
store 10 finish heartbeat, cost time: 6.436020432s
store 1 finish heartbeat, cost time: 6.722400486s
store 5 finish heartbeat, cost time: 6.770380942s
store 9 finish heartbeat, cost time: 6.897113515s
store 17 finish heartbeat, cost time: 7.038131066s
store 19 finish heartbeat, cost time: 7.103957553s
store 18 finish heartbeat, cost time: 7.15742659s
store 13 finish heartbeat, cost time: 7.204494695s
store 4 finish heartbeat, cost time: 7.235026932s
store 15 finish heartbeat, cost time: 7.339481592s
store 20 finish heartbeat, cost time: 7.445103063s
store 7 finish heartbeat, cost time: 7.496123163s
store 11 finish heartbeat, cost time: 7.557848061s
store 6 finish heartbeat, cost time: 7.642173479s
store 14 finish heartbeat, cost time: 7.690908351s
store 12 finish heartbeat, cost time: 7.730360049s
store 16 finish heartbeat, cost time: 7.738155807s
store 3 finish heartbeat, cost time: 7.758237394s
store 8 finish heartbeat, cost time: 7.760809272s
store 2 finish heartbeat, cost time: 7.78686491s

Summary:
  Total:	7.7870 secs.
  Slowest:	0.9230 secs.
  Fastest:	0.0000 secs.
  Average:	0.0001 secs.
  Stddev:	0.0049 secs.
  Requests/sec:<PHONE_NUMBER>

Response time histogram:
  0.0000 [1]	|
  0.0923 [999526]	|∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  0.1846 [341]	|
  0.2769 [91]	|
  0.3692 [30]	|
  0.4615 [7]	|
  0.5538 [16]	|
  0.6461 [5]	|
  0.7384 [1]	|
  0.8307 [0]	|
  0.9230 [2]	|

Latency distribution:
  10% in 0.0000 secs.
  25% in 0.0000 secs.
  50% in 0.0000 secs.
  75% in 0.0000 secs.
  90% in 0.0000 secs.
  95% in 0.0000 secs.
  99% in 0.0000 secs.
  99.9% in 0.0292 secs.

Sample in one second (unix latency throughput):
UNIX-SECOND,MIN-LATENCY-MS,AVG-LATENCY-MS,MAX-LATENCY-MS,AVG-THROUGHPUT
1571327181,790ns,718.352µs,923.025794ms,21936
1571327182,811ns,2.116386ms,575.663412ms,8005
1571327183,791ns,1.295264ms,304.157804ms,15346
1571327184,781ns,1.227551ms,280.918715ms,16183
1571327185,797ns,64.571µs,321.393424ms,253907
1571327186,897ns,131.986µs,598.345544ms,153543
1571327187,810ns,159.222µs,482.964175ms,117819
1571327188,820ns,35.152µs,107.004495ms,367189
1571327189,1.049µs,21.428µs,17.978842ms,46092

It seems the output histogram is not well-formatted.

Codecov Report

Merging #1814 into master will increase coverage by 0.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1814      +/-   ##
==========================================
+ Coverage      78%   78.19%   +0.19%
==========================================
  Files         167      167
  Lines       16473    16557      +84
==========================================
+ Hits        12849    12947      +98
+ Misses       2580     2571       -9
+ Partials     1044     1039       -5

Impacted Files
Coverage Δ

server/kv/etcd_kv.go
70.12% <0%> (-9.1%)
:arrow_down:

server/schedulers/random_merge.go
62.5% <0%> (-5%)
:arrow_down:

server/namespace_cluster.go
86.11% <0%> (-2.78%)
:arrow_down:

server/member/leader.go
77.04% <0%> (-1.54%)
:arrow_down:

server/schedulers/balance_region.go
84.33% <0%> (-0.46%)
:arrow_down:

server/core/store.go
78.59% <0%> (-0.26%)
:arrow_down:

server/schedule/operator/operator.go
85.32% <0%> (-0.21%)
:arrow_down:

server/schedulers/balance_leader.go
96.63% <0%> (-0.14%)
:arrow_down:

pkg/etcdutil/etcdutil.go
88.4% <0%> (ø)
:arrow_up:

server/config/option.go
91.85% <0%> (+0.06%)
:arrow_up:

... and 15 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f1f4553...7b0f081. Read the comment docs.

@rleungx You are right, the problem may in Report package, may need to fix it in etcd.


Add to VL ecosystem page

This project looks really useful. When you are ready, please send a pull request to add it to https://vega.github.io/vega-lite/ecosystem.html.

Thanks for attention! We still have many items on our to-do list (I’m transfer them to GitHub projects). I will send a PR when it’s ready.
🙋♂ By the way, if you have any comments or suggestions, feel free to open new issues.

Sounds good. One high level question I have is what features you think could be added to the Vega editor.

@domoritz Yue and I had a discussion. We think that to show complete data flow graphs are not so helpful at all because they are usually complicated (dozens of nodes and convoluted edges). Also, for people who just want to make things work, data flow graphs are unnecessary. Showing a simplified data flow graph is better. But how to make the data flow graph readable and meaningful is still worth pondering.
Besides, to show scene graphs is a good idea: we could add a panel exhibiting the scene graph tree and users could read a node’s attributes by selecting it (just like the ”Elements” tab in browser devtools). I think this is quite useful in debug, for example, if I want to know some attributes of a mark is successfully bound or the related signal is correctly evaluated.

I agree with both of these points.
Another idea I have is some way (e.g. a button in the editor UI) to load a chart in the inspector when necessary.

This is a good idea. So I think we can:

place the scene graph viewer in the bottom of Vega editor’s preview panel (together with data viewer and signal viewer),
keep data flow inspector as a standalone tool, and
offer a button to load charts in data flow inspector.

How do you think?
Now I’m working on the scene graph viewer. It‘ll be released soon.

Sounds like a plan.


Sprite tag issue

When having a  tag, the script assumes it requires a closing  and adds it to the final text that's being printed. Also for some reason the sprite appears as soon as the typing appears instead of being "typed".

Thanks for the bug report! This might be a quick fix - there are likely
issues because I haven't testing it with Text Mesh Pro much at all.
If I get some bonus time soon I'll look into it. But otherwise it will be a
bit.
On Thu, Oct 25, 2018 at 3:31 PM TrapShooter<EMAIL_ADDRESS>wrote:

When having a tag, the script assumes it requires a closing and adds it to
the final text that's being printed. Also for some reason the sprite
appears as soon as the typing appears instead of being "typed".
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/redbluegames/unity-text-typer/issues/17, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAYUKQiuO9CyvAcpbYTpzAhTh90r4V-jks5uohF7gaJpZM4X69Ql
.


[bug] Metamask not opening automatically on triggering Wagmi write function on Mobile

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
0.12.2
wagmi Version
0.12.4
Current Behavior
on triggering write action from Wagmi for any available contract methods, Meta mask not opening, need to open it manually and then accept the transaction there.
this is only happening on Mobile android and IOS, the web is working perfectly.
Expected Behavior
write action should open or switch to meta mask as the wallet is already connected.
Steps To Reproduce

connect wallet through meta mask
Run any write action in your contract

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
No response

@Mohamed-kassim Are you using the MetaMask in-app browser, or Safari/Chrome and connecting via WalletConnect?

I'm having a similar problem trying to sing a message in mobile, although the connection is working well when I try to launch signMessage is not doing anything

when i switch network is not navigating to metamask

I believe we fixed this with #1145. Just released as 0.12.7. Let me know if you're still experiencing the issue.


Added introductory example notebooks

Added notebooks for the following topics:

Introduction to Python
Introduction to Python Packages
ML Example 1 - Iris flower classification

This might need changes to fit into the Quarto website's .qmd-based file structure.

Manually rebased and merged (commit 8b0ab1d)


Allow "time" options to be specified

Bug or Feature Request?
Feature request
Description
Allow the time options to be specified.
How to reproduce
N/A
Live demo demonstrating bug
N/A
Versions

React JSX Highcharts version: 3.1.0
Highcharts version: 6.0.7
React version: 16.5

Hi @jacobweber, you can supply a timezone by passing a time prop to your HighchartsChart component
Example: https://stackblitz.com/edit/base-chart-example-73axnx?file=MyChart.js
It's worth noting though, Highcharts requires you to expose moment on the global window object for timezone features to work 😞, which is why it might seem like this feature doesn't work.


requirements中没有streamlit，直接运行示例程序会报错

Describe the bug
直接运行streamlit run llm_os_demo.py会提示没有streamlit
按照llm_os_demo.py中的提示安装完额外所需依赖后再运行, 报如下错误
Traceback (most recent call last):
  File "/miniconda3/lib/python3.12/site-packages/agentica/emb/text2vec_emb.py", line 9, in <module>
    from text2vec import SentenceModel
  File "/miniconda3/lib/python3.12/site-packages/text2vec/__init__.py", line 8, in <module>
    from text2vec.bertmatching_model import BertMatchModel
  File "/miniconda3/lib/python3.12/site-packages/text2vec/bertmatching_model.py", line 11, in <module>
    import torch
ModuleNotFoundError: No module named 'torch'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/miniconda3/lib/python3.12/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 589, in _run_script
    exec(code, module.__dict__)
  File "/agentica/examples/llm_os_demo.py", line 22, in <module>
    from agentica.emb.text2vec_emb import Text2VecEmb
  File "/miniconda3/lib/python3.12/site-packages/agentica/emb/text2vec_emb.py", line 11, in <module>
    raise ImportError(
ImportError: `text2vec` not installed. Please install it with `pip install text2vec`
2024-07-04 09:23:40.786 Uncaught app exception
Traceback (most recent call last):
  File "/miniconda3/lib/python3.12/site-packages/agentica/emb/text2vec_emb.py", line 9, in <module>
    from text2vec import SentenceModel
  File "/miniconda3/lib/python3.12/site-packages/text2vec/__init__.py", line 8, in <module>
    from text2vec.bertmatching_model import BertMatchModel
  File "/miniconda3/lib/python3.12/site-packages/text2vec/bertmatching_model.py", line 11, in <module>
    import torch
ModuleNotFoundError: No module named 'torch'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/miniconda3/lib/python3.12/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 589, in _run_script
    exec(code, module.__dict__)
  File "/agentica/examples/llm_os_demo.py", line 22, in <module>
    from agentica.emb.text2vec_emb import Text2VecEmb
  File "/miniconda3/lib/python3.12/site-packages/agentica/emb/text2vec_emb.py", line 11, in <module>
    raise ImportError(
ImportError: `text2vec` not installed. Please install it with `pip install text2vec`

To Reproduce
git clone https://github.com/shibing624/agentica.git
cd agentica
pip install .
cd examples
pip install streamlit agentica text2vec sqlalchemy lancedb pyarrow yfinance
streamlit run llm_os_demo.py

Describe your attempts

[ √ ] I checked the documentation and found no answer
[ √ ] I checked to make sure that this is not a duplicate issue

You should also provide code snippets you tried as a workaround, StackOverflow solution that you have walked through, or your best guess of the cause that you can't locate (e.g. cosmic radiation).
Context

OS [e.g. Windows 10, macOS 10.14]: Ubuntu 22.04.4 LTS
Hardware [e.g. CPU only, GTX 1080 Ti]: RTX 4090

Additional Information
Other things you want the developers to know.

pip install torch


IP Type Group by Select Sorting Issue

CrateDB version : 4.1.4
OS version / environment description: CentOS 7.4
Problem description:
The result of Group by select order by IP type is not displayed correctly.
If I select without Group by, it is displayed normally. May be Bug?
Even if I order by using TYPE CAST, it is not displayed correctly.
== result of group by select ==
select ipaddr, bytes from (
select ipaddr, sum(byte) as bytes from test_hist group by ipaddr
) A order by A.ipaddr asc limit 100

<IP_ADDRESS>, 100
<IP_ADDRESS>, 200
<IP_ADDRESS>, 140

== result of no group by select ==
select ipaddr, byte from test_hist order by ipaddr asc limit 100

<IP_ADDRESS>, 10
<IP_ADDRESS>, 20
<IP_ADDRESS>, 100

== result of group by select with type cast ==
select ipaddr, bytes from (
select ipaddr, sum(byte) as bytes from test_hist group by ipaddr
) A order by A.ipaddr::ip asc limit 100

<IP_ADDRESS>, 100
<IP_ADDRESS>, 200
<IP_ADDRESS>, 140

The result of Group by select order by IP type is not displayed correctly.
If I select without Group by, it is displayed normally. May be Bug?
Even if I order by using TYPE CAST, it is not displayed correctly.

Depends on which ordering you consider correct.
<IP_ADDRESS>, 100
<IP_ADDRESS>, 200
<IP_ADDRESS>, 140

Is sorted alphanumerically. Which would be the expected ordering (we currently expose IPs as string or text to clients).
The order returned by select ipaddr, byte from test_hist order by ipaddr asc limit 100 is wrong.


[approval-tests-cpp] Update to 10.10.0

Update approvaltests to v10.10.0

Does your PR follow the maintainer guide?
yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?
No, only ran ./vcpkg x-add-version approval-tests-cpp
didn't see the --all in the docs.
Please let us know if this is needed, thanks

The 'paraview' breaks due CI basline error,just wait CI error fixed.

The 'paraview' breaks due CI basline error,just wait CI error fixed.

We are assuming this means there is NO action for us to take at the moment, if this is incorrect, please tell us.

/azp run

no pressure, but wanted to check if there is anything we should do to make these easier/quicker to accept.
thanks


Update infrastructure to the new "Factory" objects for Systematic Firecrown

New version of Firecrown makes it much easier to get a dictionary of systematic parameters from the likelihood (which then can easily get it from the SACC file).
To Do:

[ ] Update to Firecrown 1.8
[ ] Test implementing these capabilities in the blinding infrastructure
[ ] Re-write the examples to match these changes
[ ] Update the unit tests

More information here: https://firecrown.readthedocs.io/en/latest/_static/two_point_generators.html

Firecrown 1.8 is not yet release. This is issue should wait development until it is.


.and_sample(n) does't work as expected

Describe the problem
.and_sample(n) does't work as expected as n < 3
Steps to reproduce the problem
See https://github.com/vochicong/csv_step_importer_sample/blob/master/spec/performance/book_importer_spec.rb#L15
Actual behaviour

.and_sample(n) doesn't work for n = 1, 2, it will run 3 times
.and_sample(-1) seems to run once, but sometimes it seems to run 3 times.

Expected behaviour

Default sample to be 1
.and_sample(n) work for n < 3

Describe your environment

OS version: CircleCI
Ruby version: 2.4
RSpec version: 3.8
RSpec::Benchmark version: 0.3

Hi Cong,
Thanks for using the gem and reporting this issue!
This issue should be fixed on master branch. Can you point your gem dependency source directly at this repository? I will release shortly. One thing I'm planning to do is to change and_sample to be named sample instead. This is confusing for anyone using compound rspec matchers.
I don't think having sample size to be 1 is an optimal default for most cases. One measurement is not enough to establish benchmark for any case, you want to run it few times to have more accurate measurement and thus prevent your tests from being flaky and failing for no reason, because the Ruby vm took longer to garbage collect or warmup. You want to minimize the effect of outliers.

Thank you.
I think that I can wait until you release a new version. And sample sounds better than and_sample.
I understand that a default sample size of 1 is not good for a benchmark,but it won't surprise a 1st time user like me.
It'd be better if one can set a default sample size in a config file so that one doesn't need to repeatedly specify them same sample size in RSpec.

On reflection, I've changed the default sample size to be 1 and anything below that value will raise an error.

Released v0.4.0 with the new api.

Thank you @piotrmurach


[fix][client] Fix messages in the batch container timed out unexpectedly

Fixes https://github.com/apache/pulsar/issues/21884
Motivation
When ProducerImpl#run is called where pendingMessages is empty and batchMessageContainer is not empty, the whole batch's timestamp is treated as lastBatchSendNanoTime + batch latency.
Given send timeout as 5 seconds, assuming a batch was flushed at t1 and the next message was sent after 5 seconds:

t1: ProducerImpl#batchFlushTask(), lastBatchSendNanoTime is now t1
t1 + 0.0011 s: ProducerImpl#run(), no pending message and the batch container is empty
t1 + 5.0010 s: sendAsync(), the message is added to batch
t1 + 5.0011 s: ProducerImpl#run() is called before batchFlushTask()

https://github.com/apache/pulsar/blob/176bdeacd309e8c1e49358987a1946abd30ba34a/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ProducerImpl.java#L2014-L2015
createdAt will be t1 + 0.001 s. However, the current time point is t1 + 5.0011 s, the interval is 5.001 s, timeout happened.
Modification
Record the timestamp when the 1st message is added to the batch container and use this timestamp instead of lastBatchSendNanoTime to compute the createdAt.
Add testSendTimerCheckForBatchContainer to cover this case.
Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

@nodece It's not hard to reproduce. The open sourced KoP can also reproduce this issue.

Run a KoP standalone
Run a Kafka consumer via CLI (./bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my-topic --group my-group)
Just wait. If it is not reproduced after some time, try unloading the public/__kafka namespace and wait. (./bin/pulsar-admin namespaces unload public/__kafka)

I reproduced again just now.
2024-01-16T11:33:12,414+0800 [pulsar-web-49-19] INFO  org.apache.pulsar.broker.admin.impl.NamespacesBase - [null] Unloading namespace public/__kafka

[2024-01-16 11:33:50,344] WARN [Consumer clientId=console-consumer, groupId=my-group] Offset commit failed on partition my-topic-0 at offset 0: The request timed out. (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator)

After about 40 seconds since unloading, the timeout error occurred.

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (176bdea) 73.58% compared to head (4c868c3) 73.55%.
Report is 6 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #21889      +/-   ##
============================================
- Coverage     73.58%   73.55%   -0.03%
- Complexity    32325    32347      +22
============================================
  Files          1859     1859
  Lines        138263   138373     +110
  Branches      15153    15160       +7
============================================
+ Hits         101736   101779      +43
- Misses        28644    28702      +58
- Partials       7883     7892       +9

Flag
Coverage Δ

inttests
24.18% <50.00%> (+0.08%)
:arrow_up:

systests
23.68% <50.00%> (-0.10%)
:arrow_down:

unittests
72.83% <93.75%> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

...sar/client/impl/AbstractBatchMessageContainer.java
79.54% <100.00%> (+3.86%)
:arrow_up:

.../pulsar/client/impl/BatchMessageContainerImpl.java
80.89% <100.00%> (+0.21%)
:arrow_up:

...sar/client/impl/BatchMessageKeyBasedContainer.java
65.30% <100.00%> (+1.47%)
:arrow_up:

...va/org/apache/pulsar/client/impl/ProducerImpl.java
83.01% <80.00%> (-0.29%)
:arrow_down:

... and 64 files with indirect coverage changes


feat: implement 0xFD REVERT

Since
Byzantium
Group
System Operations
Description
0xFD - REVERT
Stop the current context execution, revert the state changes (see STATICCALL for a list of state changing opcodes) and return the unused gas to the caller. It also reverts the gas refund to its value before the current context. If the execution is stopped with REVERT, the value 0 is put on the stack of the calling context, which continues to execute normally. The return data of the calling context is set as the given chunk of memory of this context.

May I open a PR on this one?

@pedrobergamini sure, welcome onboard! Can you please share here a bit of the technical strategy you want to implement? It can avoid rework, we'll be happily give you feedback on it and answer questions if you have

Hey @matthieuauger! I was discussing with @Eikix and @LucasLvy in telegram, the idea is to initially implement this using Starknet's native revert and just reading the return data to create a shortstring from it and use it as the revert reason.

Awesome! LFG 🚀

Opened a PR, let me know what you guys think on the implementation suggestion #277


[GitLab] Fix dynamic color for Menu Bar command icons

Description

Fixes the dynamic color for the GitLab Menu Bar command icons, specifically the Merge Request one.
Changed strings referencing the "mropen.png" to use the GitLabIcons enum instead.

Screencast
Here are some screenshots when having a light and a dark Desktop background:

Here's a screenshot from the MR MenuBarItem icons:

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[ ] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[ ] I checked that assets used by the README are placed outside of the metadata folder

Could you give this a spin @tonka3000


Text classification with IMDB

To show how to use user-defined web service to host a text classification model

@MRXLT will give a tutorial about training and serving with IMDB dataset.

https://github.com/PaddlePaddle/Serving/blob/develop/doc/TRAIN_TO_SERVICE.md