.gitignore for .vscode

I'm wondering if there is a way to detect if the source loaded is within a git context and, if so, either add to or create (prompting) the .gitignore to include .vscode folder - right now having to do that manually.

@DualBrain
Which .gitignore are you referring to? The one for the extension project or the QB64 project (where the bas file are)?
If its in the one in the QB64...
Editing a .gitignore is doable.
I'm not sure how to check if within a git context. But I had a template; creating a new one can be done as well.
At this point I'm not sure how to do a prompt (might be as easy as just calling Alert).
So if I'm reading this correctly 2 things need to be done

Editing and exiting .gitignore
Create a .gitignore if it does not exist.

About the one in the opened .bas file.  In my case, .bas files are in c:\bas and/or c:\github\projectname - not in the c:\qb64 executable folder.  Whenever I open with a .bas file with the extension active it creates a .vscode folder and that doesn't really present itself as a problem until I go to review my commit to github. ;-) It's easy enough to work around, but if it could be automated that would be a lot better.
Your #1 and #2 are correct.  The challenge as I see it is accurately detecting the root of the github "project" as it might not be in the same folder as the .bas file but in a parent (or parent's parent) folder.

The creating of the .vscode folder currently always happens in the same folder that .bas file is in.   That is so the launch.json gets created thus allowing the F5 to work.
I see show this could be a problem.  We would need to find the parent's .gitingore then add .vscode for that folder and all sub-folders.
A quick fix that would be better than the nothing we have now; is if there is a .gitingore in the same folder as the .bas add the .vscode folder to it.
That won't fix your problem, but anyone how keeps all their .bas files in the root of the project and puts the include files in sub folders would be fixed.

I think .gitignore works in subfolders as well as the parent, so having multiple isn't necessarily an issue - I tend (personal work patter) try to keep "projects" in their own subfolders.

And to me adding a .gitignore is "good" while having a "personal" .vscode in the repo is "bad". ;-)

What all do you think should be in the gitignore

If I recall off the top of my head, I think it's...
.vscode/

Found this...
https://stackoverflow.com/questions/56792135/gitignore-ignore-all-vscode-directories-but-include-the-top-level-launch-json
I'm not sure it's a good idea to include the launch.json file at this point given that things might change... but, it does seem there's some argument for excluding everything but this file.  Food for thought.

I agree including the launch.json at this point is not what we want to do.
I'm thing for now I'll create the .gitignore in the same folder the bas file is in.  And see how that works out.  Then go from there.

I have the the creating of a gitignore working (if it's not already there and the setting for it is true)
But I was thinking (if it's not crazy hard) what would be better than auto adding stuff to the file. Would be adding a right click option to the VSCode explorer context menu to add to .gitignore.
So summing up add an option here.  Called "Add to .gitignore"  then what ever you right clicked on gets added.

Getting the menu option there was pretty easy (both files and folders). Now to make do something


Persisting autocomplete object - TypeError: can't pickle _thread.lock objects

I am using this library in a lambda function for autocomplete in a search box.
A POST request is sent with the search string to the lambda function, which returns the top 10 alphabetical matches from the DWG. (I will eventually use count when I have figured out a method of ranking the responses).
To speed things up, I want to build the autocomplete object, store it in s3, and then load it in the lambda function instead of having to build the dwg each time.
When I try to pickle the autocomplete object, I get this error message:  "TypeError: can't pickle _thread.lock objects"
I think it's something to do with multiprocessing, lock, queue or logger, but I have no experience with any of that stuff so I'm at a loss.
Is there a way to get round this - either by persisting the autocomplete in a different way, or making it pickle-able?
Thanks

Interesting. What you could do is to pickle self._dwg because that's the graph once populated. Then instantiate AutoComplete with an empty dictionary or words. Then overwrite self._dwg
So:
# ac is the autocomplete object.
dump = pickle.dumps(ac)

# Load it via lambda
ac = Autocomplete(words={})
ac._dwg = pickle.loads(dump)

I think you should get a better performance if you have a server that runs autocomplete and the edge nodes call that service to get the results.

Hi @hblauth
Did that work?

Yes! Thanks very much.


Promise polyfill is not exported to 'window' if CommonJS is used

This piece of code in Promise polyfill makes the whole polyfill file export the Promise object and prevents its export to window if CommonJS modules are used:
    if (typeof module != 'undefined' && module.exports) {
        module.exports = global.Promise || Promise;
    } else if (!global.Promise) {
        global.Promise = Promise;
    }

That looks strange, I think polyfill should always export it to window as it imitates native behavior.

This is a fairly common approach to making code with multiple module system compatibility. In the polyfill service it is ineffective and will always export the API to Promise on the global object, because there is no module.exports in the browser.
We prefer to retain polyfill source as originally written if it is not causing a problem, since it makes it easier for us to update.


Fix grammar & spelling

Nothing fancy here, just grammar & spelling fixes.

Thanks a lot for reviewing all the doc, really appreciate it!


ORC-1017: Add sizes tool to determine and display the sizes of each column in a set of files.

What changes were proposed in this pull request?
This patch adds a new tool that accounts for the total size of a set of ORC files. For files written by >= ORC 1.5, you'll get a column breakdown of the file. There are some virtual columns that are included:

_index the indexes that are used for skipping inside the stripe
_data the data in files written prior to ORC 1.5
_stripe_footer the stripe metadata
_file_footer the file metadata
_padding padding added to align stripes to HDFS block boundaries

I also added a new method on TypeDescription that gets the full field name, which is the inverse of findSubtype.
Why are the changes needed?
The tool helps diagnose the compression of a set of files.
How was this patch tested?
I added a test of the new TypeDescription.getFullFieldName. I ran the tool over some of the examples and some multiple-terabyte directories of production ORC files.

Let me take a look the CI failure.

I re-triggered the GitHub Action .

Since this is mostly tools-only change, I backported this to branch-1.7.


Changed the login node names.

holylogin01, ...holylogin04 were retired and these should not exist in our document. I removed them from the files "using_vscode_for_remote_development.md" and "accessing_and_navigating_the_cluster.md".
The handbook refers only to "login.rc.fas.harvard.edu".

Spotted and removed holylogin description in the file using_vscode_for_remote_development.md

I am closing the pull request since the branch got conflict due to the name change. I will open a new pull request.


Dropped support for Python < 3.8

coverage: 25.088%. remained the same
when pulling 102529eb3799b345f50873d633a4c275d53e8f85 on andy/drop-below-py38
into 28b17c4ce7bfeb7d4d88a9adce1e2d3ed4e1e7ed on master.

coverage: 25.088%. remained the same
when pulling 02852e995c04c886ea5174239dc9b801f28ec8ed on andy/drop-below-py38
into 28b17c4ce7bfeb7d4d88a9adce1e2d3ed4e1e7ed on master.


[macOS] Add synopsis to the select-xamarin-sdk-v2.sh

Description
Adding synopsis to the select-xamarin-sdk-v2.sh, so it will be more obvious to customers how to use it and what it does.

Related issue: https://github.com/actions/virtual-environments-internal/issues/2242
Check list

[x] Related issue / work item is attached
[n\a] Tests are written (if applicable)
[n\a] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run macos1015


Include Dunfell

Thanks, why not update master branch based on this to keep it compatible also with the 3.2 Gatesgarth? I can send PR with that.


Add React on Rails configuration

https://github.com/shakacode/react_on_rails/issues/9
Pair with Mario(@mapreal19)

We could merge this one for now because this pull request only for introducing configurations. We could deal with multiple bundle files if necessary in separate pull request.

LGTM!


WIP: Sensor API channel definitions

This PR is a WIP and an attempt to define an initial list of valid sensor 'channels' (or types), along with the SI units and scale associated with them.
Further discussion is needed to refine, expand or restrict the current list.

There is (clearly) room for discussion here, but an attempt has been made at providing a more scientifically precise representation of physical concepts like light, and to allow some level of precision with concepts like distance.
You can use a generic 'straight line' type distance measurement via:
	/**
	 * Distance in a straight line (regardless of obstacles) between the
	 * source of the measurement and a specific reference point.
	 *
	 * Expressed in meters (m).
	 */
	DEV_CHANNEL_POS_DIST,

Or opt for a more nuanced, but potentially clearer distance along the surface of an object (think Haversine, etc.), which is likely more accurate in certain real-world uses cases:
	/**
	 * Distance in a straight line along the surface of an object (such as
	 * a sphere) between the source of the measurement and a specific
	 * reference point.
	 *
	 * Expressed in meters (m).
	 */
	DEV_CHANNEL_POS_DIST_SURF,

Light Measurements
The series of light measurements are more complex on the surface (compared to the previous red; 'green, bluetype values), but I believe they are scientifically fare more accurate and ultimately flexible, and generic information like relative RGB values can easily be inferred from multiple instances ofDEV_CHAN_LIGHT_IRRAD_COMP`, without being locked into an overly narrow RGB tuple:
	/**
	 * Irradiance limited to a specific spectral component. The exact
	 * wavelength or wavelength range of the component should be
	 * indicated with an appropriate channel attribute.
	 *
	 * Expressed as watts per square meter (W/m^2).
	 */
	DEV_CHAN_LIGHT_IRRAD_COMP,

A clear distinction has also been made between radiometric and photometric units.
Lux has it's own dedicated channel:
	/**
	 * An approximation of human vision, which is the result of a
	 * conversion from irradiance (a radiometric unit expressed in
	 * W/m^2) to illuminance (a photometric unit expressed in lumen/m^2)
	 * by means of a version of the CIE luminous efficiency function.
	 *
	 * ?PTE: More technically, this channel should probably be named
	 *       `ILLUMINANCE`, but `LUX` is used as present since it is
	 *       a significantly more familiar concept to most people.
	 *
	 * Expressed as 'lux', or more precisely lumens per square meter.
	 */
	DEV_CHAN_LIGHT_LUX,

And there are a number of radiometric units for specific wavelength ranges, for example:
	/**
	 * Irradiance in the ultaviolet range (nominally <380 nm).
	 *
	 * Expressed as watts per square meter (W/m^2).
	 */
	DEV_CHAN_LIGHT_IRRAD_UV,

Position Data
An attempt has been made at providing a way to encapsulate basic positional data, though some discussion is likely required here. I believe most key concepts around geo-localisation can be encapsulated in the following channel types, though, with both generic and specialized versions defined where appropriate:
	/**
	 * Latitude in a geo-localisation system.
	 *
	 * Expressed as a degree/minute/second notation string.
	 */
	DEV_CHAN_POS_LATITUDE,

	/**
	 * Longitude in a geo-localisation system.
	 *
	 * Expressed as a degree/minute/second notation string.
	 */
	DEV_CHAN_POS_LONGITUDE,

	/**
	 * The altitude or 'height' of an object or point in relation to an
	 * unspecified reference level (ground, sea-level, another object,
	 * etc.)
	 *
	 * Expressed in meters.
	 */
	DEV_CHAN_POS_ALT,

	/**
	 * The altitude or 'height' of an object or point in reference to sea
	 * level.
	 *
	 * Expressed in meters.
	 */
	DEV_CHAN_POS_ALT_SEALEVEL,

	/**
	 * The altitude or 'height' of an object or point in reference to the
	 * ground immediately below the point of measurement.
	 *
	 * Expressed in meters.
	 */
	DEV_CHAN_POS_ALT_GND,

	/**
	 * Distance in a straight line (regardless of obstacles) between the
	 * source of the measurement and a specific reference point.
	 *
	 * Expressed in meters (m).
	 */
	DEV_CHANNEL_POS_DIST,

	/**
	 * Distance in a straight line along the surface of an object (such as
	 * a sphere) between the source of the measurement and a specific
	 * reference point.
	 *
	 * Expressed in meters (m).
	 */
	DEV_CHANNEL_POS_DIST_SURF,

	/**
	 * Proximity to an external plane or object.
	 *
	 * Expressed in millimeters (mm).
	 */
	DEV_CHANNEL_POS_PROX,

	/**
	 * Encapsulates a raw NMEA sentence from a GPS-type device
	 *
	 * Expressed as a null-terminated string, with the exact string
	 * contents determined by NMEA standard. NMEA sentences are generally
	 * limited to 79 characters plus the null-termination character.
	 */
	DEV_CHAN_POS_NMEA,

I'm not sure if DEV_CHAN_POS_NMEA is appropriate here, but I've added it for the sake of discussion.
Any comments, criticism or suggestions are of course welcome!

I'm 100% certain I'm missing several classes of sensors here, as well, and this should only be considered a starting point to a larger discussion. I'll dig through the box of sensors I have here to see what device classes I've missed that can't obviously be covered by the above enumeration.

Codecov Report

Merging #14245 into topic-sensors will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           topic-sensors   #14245   +/-   ##
==============================================
  Coverage          52.23%   52.23%
==============================================
  Files                307      307
  Lines              45469    45469
  Branches           10526    10526
==============================================
  Hits               23753    23753
  Misses             16914    16914
  Partials            4802     4802

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 aee196d...6239b74. Read the comment docs.

I think overall this is a great start, it makes me wonder if we should split units vs what it is.
I can easily place a voltage scaler in front of an A/D and change the scale to the point where my scale should be in mV or kV rather than V.
As an example of where this might be especially useful is in the case of several more recent TI digitzer chips which measure down to the femtofarads: http://www.ti.com/lit/ds/symlink/fdc1004.pdf
In the case of the raw channel data, in its 16bit form, describing the units as femtofarads seperated from "capacitance" I think makes a great deal of sense in this case but also many others. Let me know what you think.

I think overall this is a great start, it makes me wonder if we should split units vs what it is.
I can easily place a voltage scaler in front of an A/D and change the scale to the point where my scale should be in mV or kV rather than V.
As an example of where this might be especially useful is in the case of several more recent TI digitzer chips which measure down to the femtofarads: http://www.ti.com/lit/ds/symlink/fdc1004.pdf
In the case of the raw channel data, in its 16bit form, describing the units as femtofarads seperated from capacitance I think makes a great deal of sense in this case but also many others. Let me know what you think.

I think this makes sense, but what about keeping the current default scales, and having an optional attribute to override the defaults with some other scalar multiplier when you want a larger or smaller range (0.001x, 1000x, etc.)? This avoids the need for an extra attribute in 90% of the cases, but we still have the necessary flexibility to move things up or down several orders of magnitude if useful?

I think overall this is a great start, it makes me wonder if we should split units vs what it is.
I can easily place a voltage scaler in front of an A/D and change the scale to the point where my scale should be in mV or kV rather than V.

Along those lines, digital accelerometers come in high-g and low-g varieties, and many low-g versions have voltage scaling options (2g, 4g, 8g) before the internal A/D. Instead of drivers scaling sampled data to a common format and potentially losing precision or range, I think each driver should have an attribute that declares its fixed point representation (e.g., a Q format attribute).

@microbuilder
I'm assuming that this work will be sooner or later merged into #14008, correct?

@microbuilder
I'm assuming that this work will be sooner or later merged into #14008, correct?

Yes

Closing this pending a total rethink of the general purpose sensor API, and this PR and comments herein can be consulted at that point.


View Cell Feature ?

About View cells.
We can use the view cells only for minimum unique content.
I hit this bump. I wanted to try the feature and now i am stuck.
I have for example
a view cell that all the content to be rendered if we already loaded some on other view cells.
This is because the Request class is not passed to the controller.
How can i get already loaded params from extended controller if this view cell don`t call the
initController constructor. ?
Structure
BaseController
Home extends BaseController
[IN HOME] i use a VIEW
inside that view i use view_cell(Front/Pricing)
This is very important because i already loaded inside the Home, so all view_cells needs to have this data. How can i get this data without sessions :( ?
Front/Pricing extends BaseController

You have 2 options:

pass the needed information into the cell as parameters.
Grab the current request instance with service('request') - that provides a singleton of the request with all of the information you may need.


Request for Documentation on Parsing Rules for Trivia in swift-syntax

Description
I'd like to request documentation on the rules for parsing Trivia.
There used to be documentation explaining the rules for parsing Trivia back when we were using libSyntax,
but it seems to have disappeared since the transition to swift-syntax.
The URL at the time was as follows.
https://github.com/apple/swift/blob/980d40951ff557047dce833d1d092b400bbc20db/lib/Syntax/README.md
Just to be sure, I searched both the repository and the documentation site, but I couldn't find it.
Understanding what constitutes the trailing trivia of a preceding token and
what becomes the leading trivia of a following token
is essential for implementing tools that process code.
It's challenging to deduce this behavior from the actual behavior alone,
so I believe it's necessary to have a document that explains this.

Tracked in Apple’s issue tracker as rdar://125747258

Generally (if you don’t consider multi-line string literals, which have their own rules), all trivia up to a newline is trailing trivia and all trivia after a newline is leading trivia.


Highlight code in Markdown

Example option containing markdown in default which has a nix-code block:
programs.nixvim.plugins.yazi.settings.open_file_function

We also probably need to handle the special settings structure used by nixvim.


obc-peer crashes with "index out of range" panic in ocbpbft.witnessCheckpoint

Observed in:
commit e338d6a25865db96c4e6374168473965a2b39054
Merge: 67e2a10 15dcc91
Author: Binh Q Nguyen<EMAIL_ADDRESS>Date:   Mon Feb 15 12:10:54 2016 -0500

I have been stress-testing 4-node docker-compose networks today that use the "classic" PBFT. The setup is documented in #685. The network is set up, chaincode_example02 is deployed, and then simple "a gives b 1" transactions are invoked as fast as possible. These setups routinely crash. I have seen #676 appear in the logs, but observed what appears to be a new issue just now. This is from peer vp0, the peer targeted by the transactions:
21:06:04.018 [devops] invokeOrQuery -> DEBU 583e Sending invocation transaction (68971f80-2dc8-4428-bd41-885c8a0a5775) to validator
21:06:04.018 [state] AddChangesForPersistence -> DEBU 583f state.addChangesForPersistence()...start
21:06:04.018 [buckettree] getAffectedBuckets -> DEBU 5840 Adding changed bucket [level=[5], bucketNumber=[8618]]
21:06:04.018 [buckettree] getAffectedBuckets -> DEBU 5841 Adding changed bucket [level=[5], bucketNumber=[6083]]
21:06:04.019 [buckettree] getAffectedBuckets -> DEBU 5842 Changed buckets are = [[level=[5], bucketNumber=[8618] level=[5], bucketNumber=[6083]]]
21:06:04.019 [state] AddChangesForPersistence -> DEBU 5843 Adding state-delta corresponding to block number[98]
21:06:04.019 [state] AddChangesForPersistence -> DEBU 5844 Not deleting previous state-delta. Block number [98] is smaller than historyStateDeltaSize [500]
21:06:04.019 [state] AddChangesForPersistence -> DEBU 5845 state.addChangesForPersistence()...finished
21:06:04.019 [ledger] resetForNextTxGroup -> DEBU 5846 resetting ledger state for next transaction batch
21:06:04.019 [buckettree] ClearWorkingSet -> DEBU 5847 Enter - ClearWorkingSet()
21:06:04.019 [consensus/obcpbft] startTimer -> DEBU 5848 Replica 0 starting new view timer for 10s
21:06:04.019 [consensus/obcpbft] prepared -> DEBU 5849 Replica 0 prepare count for view=0/seqNo=99: 3
21:06:04.019 [consensus/obcpbft] committed -> DEBU 584a Replica 0 commit count for view=0/seqNo=99: 4
21:06:04.019 [consensus/obcpbft] stopTimer -> DEBU 584b Replica 0 stopping a running new view timer
21:06:04.019 [consensus/obcpbft] executeOne -> INFO 584c Replica 0 executing/committing request for view=0/seqNo=99 and digest tqmTl9poynmJ7OnD3jpsPoraXkRQ87Ha9XuihHsNp4s3j0+LHaQlep8gd42na8evh1PQcA1yLuVjvoiGBOspug==
21:06:04.019 [chaincode] LaunchChaincode -> DEBU 584d chaincode is running(no need to launch) : d4d637637d6a61f4ad4a3cb8ce8f3c17ade203a6f6a826fd1115cd1e3569597dfc974e2f6e298f453cf67977b119a4ad98a089c5d83ea4916fd4b0ae66051770
21:06:04.019 [state] TxBegin -> DEBU 584e txBegin() for txUuid [6778e664-372c-4014-8524-f5e93fb819b2]
21:06:04.019 [chaincode] sendExecuteMessage -> DEBU 584f [6778e664]Inside sendExecuteMessage. Message TRANSACTION
21:06:04.019 [chaincode] sendExecuteMessage -> DEBU 5850 [6778e664]sendExecuteMsg trigger event TRANSACTION
21:06:04.019 [chaincode] processStream -> DEBU 5851 [6778e664]Move state message TRANSACTION
21:06:04.019 [chaincode] HandleMessage -> DEBU 5852 [6778e664]Handling ChaincodeMessage of type: TRANSACTION in state ready
21:06:04.019 [chaincode] processStream -> DEBU 5853 [6778e664]sending state message TRANSACTION
21:06:04.019 [consensus/obcpbft] recvCheckpoint -> DEBU 5854 Replica 0 received checkpoint from replica 3, seqNo 110, digest +43eb6wm+RjdnUAZ3ESw4grQ85KvBZxARUcCxIPsaWEJqiuDEy3Z3cl4PVshbOm+PdDjiitirCqXS2/E5vmMTg==
21:06:04.019 [chaincode] processStream -> DEBU 5856 [6778e664]Received message GET_STATE from shim
21:06:04.019 [peer] DeregisterHandler -> DEBU 5857 Deregistered handler with key: name:"vp3"
21:06:04.019 [peer] sendTransactionsToThisPeer -> DEBU 5855 Marshalling transaction CHAINCODE_EXECUTE to send to self
panic: runtime error: index out of range

goroutine 19 [running]:
github.com/openblockchain/obc-peer/openchain/consensus/obcpbft.(*pbftCore).witnessCheckpoint(0xc820350500, 0xc8207b7f80)
	/go/src/github.com/openblockchain/obc-peer/openchain/consensus/obcpbft/pbft-core.go:942 +0x898
github.com/openblockchain/obc-peer/openchain/consensus/obcpbft.(*pbftCore).recvCheckpoint(0xc820350500, 0xc8207b7f80, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/openchain/consensus/obcpbft/pbft-core.go:999 +0x271
github.com/openblockchain/obc-peer/openchain/consensus/obcpbft.(*pbftCore).recvMsgSync(0xc820350500, 0xc82336f720, 0x3, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/openchain/consensus/obcpbft/pbft-core.go:528 +0xe24
github.com/openblockchain/obc-peer/openchain/consensus/obcpbft.(*pbftCore).receive(0xc820350500, 0xc8233c2cb0, 0x62, 0x62, 0x3, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/openchain/consensus/obcpbft/pbft-core.go:487 +0x23e
github.com/openblockchain/obc-peer/openchain/consensus/obcpbft.(*obcClassic).RecvMsg(0xc820197b60, 0xc8208d1800, 0xc8203cbe60, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/openchain/consensus/obcpbft/obc-classic.go:70 +0x548
github.com/openblockchain/obc-peer/openchain/consensus/helper.(*ConsensusHandler).HandleMessage(0xc820225b90, 0xc8208d1800, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/openchain/consensus/helper/handler.go:74 +0x109
github.com/openblockchain/obc-peer/openchain/peer.(*PeerImpl).handleChat(0xc8202e2180, 0x7ff20779e360, 0xc820225b30, 0x7ff20779e510, 0xc8203ca010, 0x4e3d00, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/openchain/peer/peer.go:636 +0x679
github.com/openblockchain/obc-peer/openchain/peer.(*PeerImpl).Chat(0xc8202e2180, 0x7ff20779e4b8, 0xc8203ca010, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/openchain/peer/peer.go:277 +0xae
github.com/openblockchain/obc-peer/protos._Peer_Chat_Handler(0xd28980, 0xc8202e2180, 0x7ff20779e470, 0xc8201aa780, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/protos/openchain.pb.go:601 +0xd8
github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc.(*Server).processStreamingRPC(0xc8202dc0c0, 0x7ff20779e1b0, 0xc8203c0090, 0xc8201e00c0, 0xc8202d9140, 0x1387fe0, 0xc820225b00, 0x0, 0x0)
	/go/src/github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc/server.go:421 +0x2e4
github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc.(*Server).handleStream(0xc8202dc0c0, 0x7ff20779e1b0, 0xc8203c0090, 0xc8201e00c0, 0xc820225b00)
	/go/src/github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc/server.go:471 +0x7f4
github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc.(*Server).Serve.func2.1.1(0xc8202dc0c0, 0x7ff20779e1b0, 0xc8203c0090, 0xc8201e00c0, 0xc820225b00, 0xc8203c2030)
	/go/src/github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc/server.go:278 +0x49
created by github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc.(*Server).Serve.func2.1
	/go/src/github.com/openblockchain/obc-peer/vendor/google.golang.org/grpc/server.go:280 +0x5ac

The full log files are in the attached ZIP.
logs.zip
These tests are being run on an X86 server outside of Vagrant. Full disclosure - for consistency with my testing on POWER I am using GOLANG 1.6RC2 on both X86 and POWER, so this could be a compiler issue.

@bcbrock , can you post what you're using for the client driver ?  @corecode is in the middle of doing some perf runs. If he doesn't get to this first,  I'll try to reproduce in the morning

@tuand27613, I use the attached Tcl script (which I had to rename to .txt to attach - please remove the file extension). This script runs chaincode_example02 transactions and checks the results. It can do transactions using the CLI, REST API or using curl to send REST API calls, but the built-in HTTP/REST method is the fastest.
driveEx02.txt
To run this you will first need to need to
sudo apt-get install -y tcl tclx

You will need to modify the docker-compose scripts attached in the ZIP above to send the logs to a well-known place for your system.
To recreate:
#Start the network
dcup dc_nosec_classic_4.yml
... Wait for the network to come up ...
# Deploy example 2 - This captures the chaincode name for the next script
eval `driveEx02 <IP_ADDRESS> -deployOnly`
... Wait for the chaincode to deploy ...
# Run a single REST transaction - this should work
driveEx02 <IP_ADDRESS> -rest
# Run 1000 REST transactions and allow 30 seconds before checking - This will probably crash
driveEx02 <IP_ADDRESS> -rest -n 1000 -wait 30
# Run 4 copies of the driver each sending 1K transactions
driveEx02 <IP_ADDRESS> -rest -n 1000 -wait 30 -multi 4

When I ran this just now it failed again with the index out of range error.

@tuand27613 @bcbrock
I see what is going on here, I'll put a patch together and submit a PR

@bcbrock The way this issue is being triggered, is that a peer is falling just a little behind, then catching up, then falling a little behind again.  Although the crash is definitely a bug and is fixed in the PR above, this is probably indicative that the PBFT log size is insufficient.  You can increase the log size (and probably overall throughput) by increasing the checkpoint interval general.K in the obcpbft config.yaml.
@kchristidis Today, we set the log size statically to instance.L = 2 * instance.K // log size, this seems like it should be made configurable, or at least that multiplier of 2 should be made configurable.  I can open up an issue for this if you agree.

@jyellick,  this seems like the sort of interactions that we should document somewhere ( maybe protocol spec ? ) . We should document how to use the various options that we surface in config.yaml.

@tuand27613 There is already some documentation in the config file itself (which I think is an intuitive place for it).  You can see the description for general.K as:
    # Checkpoint period is the maximum number of pbft requests that must be
    # re-processed in a view change. A smaller checkpoint period will decrease
    # the amount of time required to recover from an error, but will decrease
    # overall throughput in normal case operation.

Are you suggesting we have a separate README.md or something like that?

A lot of the text in config.yaml is descriptive.  We can probably describe in more details the why of setting something, e.g. increase request timeout if -blah blah-  or if you set L to x then this is what happens.

@jyellick Agree. 2*K is from following the PBFT paper to the letter, but we can turn this into a parameter.
@tuand27613: Disagree. As @jyellick says, there is already a good enough amount of description in config.yaml. The user is expected to have some familiarity with the PBFT protocol.


Drop --client Java option

This option fails rspec-rails JRuby jobs with the latest JVM by emitting a warning that it's deprecated. It's better to be slower than fail.
e.g.:
Warning: the --client flag is deprecated and has no effect most JVMs

       Diff:
       @@ -1,3 +1,3 @@
        :exit_status => 0,
       -:io => (be blank),
       +:io => "Warning: the --client flag is deprecated and has no effect most JVMs\n",

It seems if any one repo has it, it poisons the environment with it somehow.

But the warning is still visible in stdout 🤔
https://travis-ci.org/github/rspec/rspec-rails/builds/665959163?utm_source=github_status&utm_medium=notification

Yep. My only suspect is that it leaks from other repos that we check out and run.
If not - I'm out of ideas where this mysterious client comes from.

It seems to be coming from the stable JRuby itself. There's not much we can do here.


Invalid CSS declarations in compiled inline styles

Hi,
I see that, when using style props like pX or pY, they are correctly converted to padding: y x but the compiled inline styles also includes invalid p-x and p-y declarations:

Awesome project btw!

Hello @bukinoshita  i will love to work on this, can i take this on?

Hello @bukinoshita  i will love to work on this, can i take this on?

Yes, feel free to take

Thanks very much. I had some trouble setting up the project repository. So I left a message on the General channel on Discord. Could you please have a look and share some feedback ? Thank you very much and sorry for the trouble.

@bukinoshita is it open? I would like to take a shot


Supporting OpenGL

I've been looking into enabling OpenGL as this is needed for the workspace flavour (aka graphic edition of NodeOS). I understand that we'll need to compile mesa, and package it into an npm module which being completely honest, really scares me. Nonetheless I'm going to give a shot at compiling mesa for the framebuffer as is accomplished here. This thread is to monitor my progress creating mesa module!

I'm thinking Mesa's dependencies might make it a pain to work with. None the less, pressing on to see where I can get to.

Maybe we could consider first starting with http://bellard.org/TinyGL/ ? It's small size makes it relatively quick and I quote from it's landing page:

TinyGL is a lot faster than Mesa

It would be a nice start for us and we could slowly grow toward the monolith mesa. Why do we need mesa? Mesa implements the full OpenGL standard, and by missing parts, we limit what programs can be run. I suggest we make it a param on the build scripts of the graphic edition to either use mesa or a smaller renderer.

Update:
So I read somewhere that TinyGL was made in 2002, making me question if it's recent enough to be used for anything at all. I will experiment with it in a bit but at the moment I'm compiling mesa. I'll have you know that mesa takes a good million years to compile, but doesn't use much ram. It's size might make it impractical but I'll have a better say on that if it finishes compiling successfully. I'm working to create an npm package that could auto compile it should we choose to use mesa in the graphic editions (therefor, I'm writing down all the commands I use and steps I follow). Mesa has been compiling for over an hour now and show's no signs of stopping... I regret not using my other core.

Update
So after 2+ hours, I was successful at compiling mesa for DRM. This is most likely what we'd use (I believe) if we were to use mesa on NodeOS so seeing that I can compile it is a good sign. I'm not quite sure what I just did however as mesa doesn't appear have created any new files (at a first glance). I'll need to investigate what was compiled, and where it is. Once I find this, it'll be a matter of hacking this build into the NodeOS build scripts to try and see if I can get it to work in NodeOS. I'll have the scripts also set everything up and it won't be a clean set up but for a first proof-of-concept prototype that should be okay.
This is full mesa so we can expect great things from it XD. I've investigated QEMU's OpenGL emulation and I believe I know what to do to get it working. Hopefully we'll have a prototype to play with soon. AS it is now 1 am (the build took longer than foreshadowed), I'm now off to sleep. Will report any new finds tomorrow!

and package it into an npm module which being completely honest, really scares me

Don't think too much on the npm package yet, let's make it work first. One step at a time ;-)
Why would we need Mesa? For node-webgl, for example? Would it need it noGUI for something? Does this compilation has hardware acceleration, or only just a software raster?

Does this compilation has hardware acceleration, or only just a software raster?

./configure --enable-gles2 --enable-gles1 --disable-glx --enable-egl --enable-gallium-egl \
     --disable-dri --with-gallium-drivers=swrast --with-egl-platforms=fbdev

Software raster, but with egl support. Ouh yeah B-) Having this compiling is a good start, it would be cool to have node-webgl to work with this :-) After that we could start enabling DRI and other things to try to have hardware acceleration using just the build in kernel drivers :-) That lead me to think... what can we do with them? Add another options on the build process to select the devices that will be included on the kernel, or should we still left to use the default kernel config?

When we've got OpenGL running, I can finally use CEF for noGUI ... Life's getting easier :D

Why would we need Mesa? For node-webgl, for example? Would it need it noGUI for something? Does this compilation has hardware acceleration, or only just a software raster?

Mesa would be an excellent OpenGL implementation for us since it can take over where hardware lacks. Mesa will use hardware acceleration where available, or software where it cannot. Right now the precise configuration I'm using enables egl coupled with soft raster as @piranna guessed. I figured it would be a good start.

./configure --enable-gles2 --enable-gles1 --disable-glx --enable-egl --enable-gallium-egl
--enable-dri --with-gallium-drivers=swrast --with-egl-platforms=drm

@piranna Mesa will be or gateway to supporting any 3D rendering be it for webgl, virtual reality, or quite literally anything using gl. We open the gates of 3D to our graphic users (which is an immense world) making NodeOS just that more powerful.
Warning
I do heavily suggest the Mesa be an optional include even for the graphic distribution as it is no small project. It's feasible and something we could actually manage to pack by the look of things, but iz definitely an extra that  select group of NodeOS users would be using. (WebGL game developers, or gamers, etc)

When we've got OpenGL running, I can finally use CEF for noGUI ... Life's getting easier :D

I've got your back!

Warning
I do heavily suggest the Mesa be an optional include even for the graphic
distribution as it is no small project. It's feasible and something we
could actually manage to pack by the look of things, but iz definitely an
extra that select group of NodeOS users would be using. (WebGL game
developers, or gamers, etc)

I think so, that's why I suggest don't work too much on the npm package
while we experiment with it, to see if we can compile it statically onto
node-webgl or CEF or whatever. We need to know before how it works and how
to integrate it before take a decission.

@piranna I'm running a second compile (this time taking advantage of all my cores) and am beginning to get an idea of how this all works. OpenGL systems dynamic. Programs using OpenGL link up with the dynamic library available on any system and they all use the same names, and interfaces so an OpenGL program could have no idea what raster it's using, whether it be a proprietary driver, or an soft-render.
To my understanding, in order to use mesa we would need to place the generated .so files in the 'lib' folder (that's created when mesa is compiled) in it's generic home so installed OpenGL programs can use it. (Be it CEF, or practically anything using OpenGL, as users may chose to swap out their renderer, who knows?). The generic home for OpenGL libraries is /usr/include/GL as noted here. I'm however curious where the /usr/bin/ gl files come from, as I don't see them in the compiled mesa project. I'll have to look deeper and maybe scavenge the net to grab their sources and additionally compile them.

@piranna I'm running a second compile (this time taking advantage of all
my cores) and am beginning to get an idea of how this all works. OpenGL
systems dynamic. Programs using OpenGL link up with the dynamic library
available on any system and they all use the same names, and interfaces so
an OpenGL program could have no idea what raster it's using, whether it be
a proprietary driver, or an soft-render.

Mostly yes, that's how the fragments connect between them in the jigsaw.

To my understanding, in order to use mesa we would need to place the
generated .so files in the 'lib' folder (that's created when mesa is
compiled) in it's generic home so installed OpenGL programs can use it. (Be
it CEF, or practically anything using OpenGL, as users may chose to swap
out their renderer, who knows?).

Here we have two options, make each user to have its own copy so they can
easily change version, or since it's related to the system hardware common
to all the users, place it on the initram of the workstation flavor similar
to how its done with libfuse. In any case, users would be able to override
it anyway...

The generic home for OpenGL libraries is /usr/include/GL as noted here.

I don't think this will be needed in a production system so it should bot
be in the initram, but it would be to build it.

I'm however curious where the /usr/bin/ gl files come from, as I don't
see them in the compiled mesa project. I'll have to look deeper and maybe
scavenge the net to grab their sources and additionally compile them.

I think we'll not need them, just only libGL.so, no more.

I think we'll not need them, just only libGL.so, no more.

Okay, awesome!

Mostly yes, that's how the fragments connect between them in the jigsaw.

Excellent. Second build done and I have all these prebuilt libs to play with. What's the easiest way to inject them into NodeOS? wget?

Here we have two options, make each user to have its own copy so they can
easily change version, or since it's related to the system hardware common
to all the users, place it on the initram of the workstation flavor similar
to how its done with libfuse. In any case, users would be able to override
it anyway...

I suggest a common installation, to avoid it's massive size being replicated and eating space pointlessly.

Mostly yes, that's how the fragments connect between them in the jigsaw.

Excellent. Second build done and I have all these prebuilt libs to play
with. What's the easiest way to inject them into NodeOS? wget?

Copy them somewhere nodeos-initramfs project inside your NodeOS
node_modules and change its scripts/build by hand to include them the same
way it's done with libfuse. Maybe you could also add them directly to its
build folder...

Copy them somewhere nodeos-initramfs project inside your NodeOS
node_modules and change its scripts/build by hand to include them the same
way it's done with libfuse. Maybe you could also add them directly to its
build folder...

Okay awesome, thanks! I'll give it a shot.

The generic home for OpenGL libraries is /usr/include/GL as noted here.
I don't think this will be needed in a production system so it should bot
be in the initram, but it would be to build it.

So it doesn't matter where we place the .so files?

The generic home for OpenGL libraries is /usr/include/GL as noted here.
I don't think this will be needed in a production system so it should
bot
be in the initram, but it would be to build it.

So it doesn't matter where we place the .so files?

As far as they end on runtime on the /lib folder it's fine.

Any ideas on what display server you're going to use?

And as a follow up, window manager?

AFAIK we won't use any display server. The apps will all be like 'normal websites'. We basically use a browser engine, currently we're using webkit but I want to swicht as soon as possible to the chormium embedded framework. Th current project can be found at the noGui repo

I was thinking of porting over Chromium OS' ash window system once I was done with my Mac ports of the build tools.

Not for the official builds, just for my own lols.

Yeah, I've looked at ash... I like it but I don't know if that matches our philosophy (@piranna, what do you think ?)

I find it the most lightweight solution to implementing a display server + window manager even though all it can display is Chromium.

Yeah... but does it use X ?

Google switched over to the Freon display stack last year: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-OS-Freon-Graphics

Do you know where the ash (or aura shell ?) source is ?

Yeah... saw that project ^^

Now I know what I'll do in my holidays ^^ Thanks for links ;)

I'd be happy to help out

Yeah, I've looked at ash... I like it but I don't know if that matches
our philosophy (@piranna, what do you think ?)

As far as we can use it without the chrome-only APIs...

Woo!

I'm going to write my own desktop/gui/window manager package for NodeOS.

Wouldn't it be more efficient if we all worked on the same project ?

I believe it would be, so who's project should we focus on?

Well I started some time ago with noGui. I think we will record our progress there. The most developed attempt is using QTwebkit and would only need some logging and some changes to the network...
However, I would love to try to make ash/aura/freon work (with nodeos) !

I'm going to get started on ash on https://github.com/joshgarde/aurora

I forgot to say in my original comment that I'd be happy to contribute code to noGui as well.

Ok... I'll add you to noGui... Will add me to aurora too ?

Done :D

Just checked out the chromium source (15GB), started building it (3 hours ago) on a new VPS I had to purchase to meet the system requirements, and realized that porting ash probably isn't worth the work.
So I'm now changing my original plans for aurora - which might be an extension of noGui for window management relying simply on EGL for display.

And now back to the main topic of this issue: How's mesa support going?

So I'm now changing my original plans for aurora - which might become an extension of noGui for window management relying simply on EGL for display.

The idea is to do everything in vanilla Javascript, if you can run it in a web browser you can run it on noGUI, so no extensions here. The only extension I would allow is the X-FRAME to disable the iframe spoofing and being able to navigate to Google or Github or Facebook from inside noGUI, and this because there are already some extensions for regular browsers that enable some whitelist sites to disable it too.

I wasn't talking about a browser extension. I'll have to explain my idea when I'm more alert (stayed up all night).
I don't feel like having a web browser within a web browser is a very good idea since one unstable website would cause the entire desktop to crash.

But I don't feel like having a web browser within a web browser is a very good idea since one unstable website would cause the entire desktop to crash.

That's why we plan to use iframes for each app, to isolate them ones from others.

A quick test in Chrome doesn't quite support this:
isolation-test.html:

<title></title>

embeded-crash.html:

Also, anything in an iframe can access the main document though window.parent

Also, anything in an iframe can access the main document though window.parent

If they are from different domains no, they don't have access.

And now back to the main topic of this issue: How's mesa support going?

I haven't gotten a chance to sit with it for the last two days but I got a lot of work hacking away at NodeOS and can now inject files right into a NodeOS workspace so I'm going to attempt to jet Mesa right into my NodeOS set up and see if I can get it going. I'll also try jetting gcc (probably g++) in there too while I'm at it to test how NodeOS handles it.

How have you done it?
El 12/7/2016 3:54, "Lite McFish"<EMAIL_ADDRESS>escribió:

And now back to the main topic of this issue: How's mesa support going?
I haven't gotten a chance to sit with it for the last two days but I got a
lot of work hacking away at NodeOS and can now inject files right into a
NodeOS workspace so I'm going to attempt to jet Mesa right into my NodeOS
set up and see if I can get it going. I'll also try jetting gcc (probably
g++) in there too while I'm at it to test how NodeOS handles it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NodeOS/NodeOS/issues/270#issuecomment-231916847, or mute
the thread
https://github.com/notifications/unsubscribe/AAgfvrPW50wYfI8IwJ79TztypcLjpZUpks5qUvPugaJpZM4JCxzA
.

How have you done it?

Yeah I did get Mesa on. G++ was however taking a billions years to compile and I couldn't finish. I'm now working on creating a simple binary using OpenGL to inject into NodeOS and test if Mesa works

That's cool :-) In case of doubts, take a look how it's done on Linux From
Scratch.
El 14/7/2016 9:57, "Lite McFish"<EMAIL_ADDRESS>escribió:

How have you done it?
Yeah I did get Mesa on. G++ was however taking a billions years to compile
and I couldn't finish. I'm now working on creating a simple binary using
OpenGL to inject into NodeOS and test if Mesa works
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NodeOS/NodeOS/issues/270#issuecomment-232590662, or mute
the thread
https://github.com/notifications/unsubscribe/AAgfvij9xMM1KGWGMlJofRj4Y2F9BW7Rks5qVev1gaJpZM4JCxzA
.

@piranna good suggestion! I've bee super busy but hopefully I'll get to play with this on Monday.

Any update on this?

I'd be happy to try my hand at this project if that's alright with @lite20

I'd be happy to try my hand at this project if that's alright with @lite20

If you are interested give it a try, maybe later would you both join efforts :-)

I'd be happy to try my hand at this project if that's alright with @lite20

Fine by me! We can use this thread to communicate. I'm working to get back to work w/o a computer (got a VPS), but I'm sure you can work faster than I with yours. I'll dump any finds here for you to work with!

Just wondering if anyone has taken a chip at this? I haven't been able to work much on NodeOS as my linux pc has been out of commission but I've got it going again. I'll mess with this a bit more and see what I can get done.
Did you make any strides @joshgarde ?

@lite20 I've been waiting for NodeOS to get to a stable build before trying to hack together any sort of GUI solution.

I do however want to still continue down the Chromium OS route and see where that can take us.

@joshgarde yeah that isn't a bad idea. I've been messing with that right now to see if I can get anything going.

There's no problem on you guys working on the UI also while NodeOS is still unstable, as I told other times by design using a regular web browser and connect to a remote NodeOS instance is a perfectly valid use case, and later move to a local web renderer would be trivial this way.

Guys this issue is Support for OpenGL, not make your own window manager, if you wanna do that go download an open source linux copy which is very good at doing those things. (Sorry if it sounds harsh)
Can this be implemented as an npm package with an accessible API?

It can be implemented but there would need to be some sort of API that accesses a framebuffer device file and somehow gets an OpenGL context for it.

Main problem is lack of time and/or sponsors to work on that :-/

@SpaceboyRoss01 I don’t think a frame buffer will do the job, in that case is easy to write /dev/fb0 as an array in nodejs, it’s the hardware driver support, am I right @piranna ? But Can’t it be ported with enscripten or the likes? Has nobody already written a port for the drivers? Time is precious to everyone indeed.


HDDS-9418. Consolidate CertificateClient handleCase handling

What changes were proposed in this pull request?

To Consolidate DefaultCertficateClient and CommonCertificateClient, and consolidate handleCase logic in all CertificateClient.
RECOVER state is removed, and is replaced by GETCERT state, to reduce the chance that a missing certificate or public key requires admin intervene to fix.

What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-9418
How was this patch tested?
tested by existing unit test with some modification.

@fapifta , @Galsza , could you help to review this patch?

@fapifta , thank you for the review.  Can you take another look of the new commit?


write_to_textfile leaves back temp files on errors

Hey.
A simple:
prometheus_client.write_to_textfile("", registry=registry)

which causes an exception:
Traceback (most recent call last):
  File "/home/calestyo/prj/prometheus-smart-array-collector/src/./smart-array.py", line 1185, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/calestyo/prj/prometheus-smart-array-collector/src/./smart-array.py", line 1176, in main
    prometheus_client.write_to_textfile("", registry=registry)
  File "/usr/lib/python3/dist-packages/prometheus_client/exposition.py", line 363, in write_to_textfile
    os.rename(tmppath, path)
FileNotFoundError: [Errno 2] No such file or directory: '.969277.139657657282624' -> ''

shows that the module doesn't properly clean up it's temp files on errors, as that file is left over afterwards.
Cheers,
Chris.

Seems reasonable to avoid leaving around tons of temporary files, though they will be cleaned up eventually. I'd be happy to accept a PR.

PTAL @calestyo @csmarchbanks


fix: cookie vulnerability

Context
Currently we have a dependency with a low security vulnerability (cookie)
https://github.com/cabify/prom-react/security/dependabot/22
Solution
We are currently using the version 0.4.2 of the library cookie (not directly, but the project has msw as a dependency and msw has cookie as a dependency pinned to the version 0.4.2).
We cannot upgrade directly the version of cookie to the earliest fixed version (0.7.0), so we have to upgrade msw. The next version of msw is the 2.0.0, which means a major upgrade with various breaking changes.
For this we have to upgrade msw following this guide

Closing this PR as the vulnerability has been fixed in https://github.com/cabify/prom-react/pull/516.


[question] can we use this bundle as a versionning tool ?

Because here it is not planned https://github.com/DATA-DOG/DataDogAuditBundle/issues/43 do you ?
Especially revert behaviour.

Hi, I'm sorry but this is not on the roadmap right now.

Though, I'd be happy to merge your PR if you want to contribute ;)

I’ve not yet test your bundle. I’ll disable datadog’s before.
Then test your to see if it fit my needs (should, because of the idea of datadog). But not implemented reverting behaviour 😋

I close this one for now

Yes I'll maybe reopen or do something else it if I found a way.

This is just a proposal, but a revert feature may be a great improvement:
https://github.com/DamienHarper/DoctrineAuditBundle/pull/98


[DEV] Clicking a Dashboard Entry Opens Applicant Viewer

Development Task 🔧
What? ❓
By clicking an element on the dashboard viewer, you can open the new applicant viewer section.

Clicking the dashboard element opens a new applicant viewer page (for this PR shouldn't contain anything)
Clicking on a button within the applicant viewer page will return to the dashboard view

Strongly encouraged to review/discuss your general approach before starting to code here!

This is merged


Use better collections framework like funk

Is your feature request related to a problem? Please describe.
Commonly used logic patterns should rely on collections framework. Because CPU load is relatively lower priority for the performance.
Describe the solution you'd like
Introduce funk or similar libraries.
Additional context

Issue
Current builder pattern may cause issues
Struct like app_control_impl.Control have a lot of fields. And builder functions may lack of copy later added fields.

Refactoring backlogs

[ ] OpenArtifact
[ ] Add subscriber to default tee logger when bootstrap logger created

[ ] Authentication always cancelled.

watermint toolbox `dev`
=======================

© 2016-2020 Takayuki Okazaki
オープンソースライセンスのもと配布されています. 詳細は`license`コマンドでご覧ください.

1. 次のURLを開き認証ダイアログを開いてください:

https://www.dropbox.com/oauth2/authorize?client_id=xxxxxxxxxxxxxxx&response_type=code&state=xxxxxxxx

2. 'Allow'をクリックします (先にログインしておく必要があります):
3. 認証コードをコピーします:
認証に失敗またはキャンセルされました: user cancelled
ERROR	Invalid argument, or unable to spin up	{"key": "Peer", "error": "user cancelled"}
ERROR	Recipe failed with an error	{"error": "user cancelled"}

[ ] Progress is not working


Fix the qa_agent_ot GitLab job

What does this PR do?
Fix the qa_agent_ot GitLab job.
Motivation
The tag of the docker image consumed by qa_agent_ot here: https://github.com/DataDog/datadog-agent/blob/04c5db04f035dbe33040df6e8a005dcfc03945e8/.gitlab/dev_container_deploy/docker_linux.yml#L298
needs to match the tag of the docker images produced by the dependencies declared here: https://github.com/DataDog/datadog-agent/blob/04c5db04f035dbe33040df6e8a005dcfc03945e8/.gitlab/dev_container_deploy/docker_linux.yml#L294-L295
and when we look at those jobs here: https://github.com/DataDog/datadog-agent/blob/04c5db04f035dbe33040df6e8a005dcfc03945e8/.gitlab/container_build/docker_linux.yml#L197
and there: https://github.com/DataDog/datadog-agent/blob/04c5db04f035dbe33040df6e8a005dcfc03945e8/.gitlab/container_build/docker_linux.yml#L211
we see that the -beta part of the suffix seems to be missing.
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

qa_agent_ot job passed: https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/561840882

Superseded by #27315.


bug: IntelliSense is broken for v18 in both VSCode and Visual Studio

Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
17
Description
Installation of angular/material v18 breaks IntelliSense/Suggestions for some types from node_modules in VSCode and VS. I tried the same repo steps using angular v17 and everything works fine.
Reproduction
Repo with this error https://github.com/IliaPodolko/vscode-imports
Steps to reproduce:

Create new angular app
ng new my-angular-project
Go to app.component.ts and try add FormsModule, you will see suggestions
Install material
npm install @angular/material
Go to app.component.ts and try add FormsModule, you will NOT see suggestions
Uninstall @angular/material and restart VSCode and after that suggestions work again.

Expected Behavior
User should see suggestions in VS and VSCode

Actual Behavior
User does not see suggestions in VS and VSCode when using angular v18 with angular/material

Environment

Angular: 18.1.3 / also tried 18..0.0 - same issue
CDK/Material: 18.1.3
Operating System: Windows_NT x64 10.0.19045
VS: 17.9.7
VSCode: 1.92.0 (2024-07-31T23:26:45.634Z)
Node: 18.20.2, also tried with v20 on another PC - same issue

I couldn't reproduce it and I don't think we format of the code we push to npm has changed for v18 so this is likely an issue on your end. cc @devversion to confirm for the npm artifcats.

I saw this issue on 3 PC.
I think I found the solution here https://www.reddit.com/r/angular/comments/1c4lsyl/how_to_set_up_vscode_intellisense_for_angular/
User PickleLips64151 says:
...Once you make the initial manual import Intellisense picks up that import for future imports in that repo...
and it helped!

Closing since this sounds like it's just how vscode works.


Figure out how to debug functional tests in Kibana

Kibana has a suite of functional tests that the CI runs with all PRs, and we can run them locally as well.
If a test fails due to a change, I would love to attach a debugger to the local Kibana instance running the functional tests to troubleshoot and solve the problem.

Requirements

Clone the repo and bootstrap Kibana for development

You need to clone the Kibana repo and bootstrap it for development. You can follow the steps at https://github.com/zmoog/public-notes/issues/59#issuecomment-1779026823. You may need to use a different nodejs version, depending on the Kibana version you plan to run

Functional Tests Overview
Kibana offers several options to run functional tests.
I will use the "best for development" option 2 for this research.
Option 2: functional test server and runner
With this option, we will:

Start a functional test server and leave it running for the whole test session.
Start a functional test runner that will execute the tests multiple times against the test server

The functional test server spawns an Elasticsearch and Kibana instance.
We aim to start the Kibana instance in the test server in debug mode so we can attach a debugger.

Start a functional test server in debug mode
I have the feeling we can simplify this step, but as of now we can start the Kibana instance in debug mode making this small change:
Enable inspect
diff --git a/packages/kbn-test/src/functional_tests/start_servers/start_servers.ts b/packages/kbn-test/src/functional_tests/start_servers/start_servers.ts
index f16b24f59bc..859c29ab5ef 100644
--- a/packages/kbn-test/src/functional_tests/start_servers/start_servers.ts
+++ b/packages/kbn-test/src/functional_tests/start_servers/start_servers.ts
@@ -50,6 +50,7 @@ export async function startServers(log: ToolingLog, options: StartServerOptions)
               ? '--server.versioned.versionResolution=newest'
               : '--server.versioned.versionResolution=oldest',
           ],
+      inspect: true
     });

     reportTime(runStartTime, 'ready', {

Set xpack.ml.enabled=false
diff --git a/x-pack/test/fleet_api_integration/config.base.ts b/x-pack/test/fleet_api_integration/config.base.ts
index 5dfea767f98..294bfda8427 100644
--- a/x-pack/test/fleet_api_integration/config.base.ts
+++ b/x-pack/test/fleet_api_integration/config.base.ts
@@ -60,6 +60,7 @@ export default async function ({ readConfigFile }: FtrConfigProviderContext) {
       serverArgs: [
         ...xPackAPITestsConfig.get('kbnTestServer.serverArgs'),
         // always install Endpoint package by default when Fleet sets up
+        `--xpack.ml.enabled=false`,
         `--xpack.fleet.packages.0.name=endpoint`,
         `--xpack.fleet.packages.0.version=latest`,
         ...(registryPort ? [`--xpack.fleet.registryUrl=http://localhost:${registryPort}`] : []),

Run the functional test runner
node \
  scripts/functional_test_runner \
  --config=x-pack/test/fleet_api_integration/config.package_policy.ts

Attach the debugger
Launch configurations
You can create a launch configurations:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Kibana Server (9230)",
            "port": 9230,
            "request": "attach",
            "restart": true,
            "skipFiles": [
                "<node_internals>/**"
            ],
            "type": "node"
        }
    ]
}

Attach!
https://github.com/zmoog/public-notes/assets/25941/2c534eaf-fc03-4205-9ac1-581cf7190603

Run the functional test runner
Set a breakpoint
Pick the piece of Kibana code you want to troubleshoot and set a breakpoint
Run!
On a different shell, run the functional test runner.
node \
  scripts/functional_test_runner \
  --config=x-pack/test/fleet_api_integration/config.package_policy.ts

When the test will cause the invocation of the code with the breakpoint:


Add header background

At the moment, the header background is a colour. Have an option to add an image that's easy to swap to something else and works on multiple screen sizes.

@jgarcia45 @junhee20park @justbustin What's the progress update on this?

We had a question @khattakdev
Do you just want us to change the background or add a button for users to change the background?


Edit ConfigureHeadstageRhs2116 remarks

The first sentence for the ConfigureHeadstageRhs2116 remarks reads awkward to me:

The Rhs2116 Headstage is a serialized headstage for small animals with 32 bi-directional channels which each can be used to deliver electrical stimuli.

Specifically, where we write "which each". I would write something like this:

The Rhs2116 Headstage is a serialized headstage for small animals with 32 bi-directional channels that can be independently  configured to record electrophysiological signals or deliver electrical stimuli.

Anyway, feel free to leave it if doesn't read awkward to you.
The relevant lines are here:
https://github.com/open-ephys/bonsai-onix1/blob/634a54c3268c65215c734e8fbbb2dcf87215bee3/OpenEphys.Onix1/ConfigureHeadstageRhs2116.cs#L11-L12

Remove small animals as well.


fix(ratelimit): Update rate limit for each endpoint.

Pull Request Test Coverage Report for Build 850

0 of 0   changed or added relevant lines in 0 files are covered.
104 unchanged lines in 4 files lost coverage.
Overall coverage remained the same at 80.423%

Files with Coverage Reduction
New Missed Lines
%

dist/routes/v2/transaction.js
6
83.98%

dist/routes/v2/blockchain.js
14
81.38%

dist/routes/v2/rawtransactions.js
22
82.09%

dist/routes/v2/address.js
62
75.63%

Totals

Change from base Build 844:
0.0%

Covered Lines:
2493

Relevant Lines:
2916

💛  - Coveralls

:tada: This PR is included in version 1.14.0 :tada:
Your semantic-release bot :package::rocket:


Consult Quality Factors [US_2]

[ ] Make and show an ordered list of all quality factors of the system (by project???)
[ ] Get single quality factor information from database
[ ] Show quality factor information

The factors should be created by project, like SIs. So, the list should be filtered by project (like SIs)

factors_management branch was merged to develop branch


Godot engine is not supported by this repo?

Hi, I'm a Godot and C# beginner, In the README.md file, it says as follows:

🚢 SUPPORT > Supports .NetStandard 2.1, .Net Core 6 and 7 and therefore you may use it with Unity or Godot!

However, I found there are some C# 11 syntaxes, like this (using the scoped keyword):
https://github.com/genaray/Arch/blob/b08cc536cd8bda035acad1e0d42a935d3f45ded5/Arch/Core/Archetype.cs#L200-L204
As far as I know, the newest Godot 4.0 support only .Net 6.0 and C# 10:

With the move to .NET 6, users can now target a newer framework that brings optimizations and new APIs. With .NET 6, projects use C# 10 by default and all features are available.

Does it mean the Godot engine is not supported by this project?

Great question !
Well the language version is actually backward compatible, C# 11 will emit slightly different he IL code.
However since godot supports .NET 6 this is no iusse. NET 6 will translate the IL Code and doesnt care if it was generated using C#11 or C#10.
Just make sure you use the nugget package and no copy of the source code ^^

I got it, thanks.

I got it, thanks.

Great to hear ! :) Let me know if you need more help or support.


Plans for mouse/Magic Remote support?

Hey guys,
I'm wondering if there are plans in the roadmap to add support for mouse interaction in the Lightning framework? It came to our attention that the LG Content Store now requires that apps support their Magic Remote (essentially a mouse from a technical standpoint). So as it stands Lightning apps are unfortunately not an option for the LG Content Store.

Hi @jonahsiegle,
We've developed some proof of concept in the past but were not able to finalise it as more important things came by. We will definitely pick this up once it becomes important for us again. So far, you can track or even contribute to POC #68.
Best regards
Duplicate #68


Jhendr m365 community

[X ] Content update
Updating community notice at top of each article.

Docs Build status updates of commit 9abbb2e:
:warning: Validation status: warnings

File
Status
Preview URL
Details

Community/includes/content-disclaimer.md
:warning:Warning
View
Details

Community/auto-apply-retention-labels-in-office-365-using-content-types-and-metadata.md
:white_check_mark:Succeeded
View

Community/benefits-of-using-powershell-with-sharepoint.md
:white_check_mark:Succeeded
View

Community/changing-microsoft-teams-from-private-to-public-what-to-expect-in-sharepoint.md
:white_check_mark:Succeeded
View

Community/designing-solution-for-scale.md
:white_check_mark:Succeeded
View

Community/empowering-your-SharePoint-champions.md
:white_check_mark:Succeeded
View

Community/glossary.md
:white_check_mark:Succeeded
View

Community/identifying-your-sharepoint-champions.md
:white_check_mark:Succeeded
View

Community/importing-data.md
:white_check_mark:Succeeded
View

Community/information-architecture-managed-metadata-vs-lookup-column.md
:white_check_mark:Succeeded
View

Community/information-architecture-site-topology.md
:white_check_mark:Succeeded
View

Community/known-folder-move-benefits-for-enduser.md
:white_check_mark:Succeeded
View

Community/library-scenarios.md
:white_check_mark:Succeeded
View

Community/list-column-or-site-column-which-one-to-choose.md
:white_check_mark:Succeeded
View

Community/machine-learning-and-managed-metadata.md
:white_check_mark:Succeeded
View

Community/managing-external-guest-in-SharePoint-vs-Teams.md
:white_check_mark:Succeeded
View

Community/new-site-checklist.md
:white_check_mark:Succeeded
View

Community/permission-model-differences.md
:white_check_mark:Succeeded
View

Community/powerplatformlicensingforcitizendeveloper.md
:white_check_mark:Succeeded
View

Community/select-an-effective-navigation-strategy.md
:white_check_mark:Succeeded
View

Community/site-design-life-cycle.md
:white_check_mark:Succeeded
View

Community/team-site-or-communication-site.md
:white_check_mark:Succeeded
View

Community/versioning-basics-best-practices.md
:white_check_mark:Succeeded
View

Community/what-is-content-type.md
:white_check_mark:Succeeded
View

Community/what-is-site-column.md
:white_check_mark:Succeeded
View

Community/working-with-modern-clientside-pages-using-pnp-powershell.md
:white_check_mark:Succeeded
View

Community/includes/content-disclaimer.md

Line 7: [Warning] Link 'https://docs.microsoft.com/en-us/sharepoint/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 8: [Warning] Link 'https://docs.microsoft.com/en-us/office/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit cc871df:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Community/auto-apply-retention-labels-in-office-365-using-content-types-and-metadata.md
:white_check_mark:Succeeded
View

Community/benefits-of-using-powershell-with-sharepoint.md
:white_check_mark:Succeeded
View

Community/changing-microsoft-teams-from-private-to-public-what-to-expect-in-sharepoint.md
:white_check_mark:Succeeded
View

Community/designing-solution-for-scale.md
:white_check_mark:Succeeded
View

Community/empowering-your-SharePoint-champions.md
:white_check_mark:Succeeded
View

Community/glossary.md
:white_check_mark:Succeeded
View

Community/identifying-your-sharepoint-champions.md
:white_check_mark:Succeeded
View

Community/importing-data.md
:white_check_mark:Succeeded
View

Community/includes/content-disclaimer.md
:white_check_mark:Succeeded
View

Community/information-architecture-managed-metadata-vs-lookup-column.md
:white_check_mark:Succeeded
View

Community/information-architecture-site-topology.md
:white_check_mark:Succeeded
View

Community/known-folder-move-benefits-for-enduser.md
:white_check_mark:Succeeded
View

Community/library-scenarios.md
:white_check_mark:Succeeded
View

Community/list-column-or-site-column-which-one-to-choose.md
:white_check_mark:Succeeded
View

Community/machine-learning-and-managed-metadata.md
:white_check_mark:Succeeded
View

Community/managing-external-guest-in-SharePoint-vs-Teams.md
:white_check_mark:Succeeded
View

Community/new-site-checklist.md
:white_check_mark:Succeeded
View

Community/permission-model-differences.md
:white_check_mark:Succeeded
View

Community/powerplatformlicensingforcitizendeveloper.md
:white_check_mark:Succeeded
View

Community/select-an-effective-navigation-strategy.md
:white_check_mark:Succeeded
View

Community/site-design-life-cycle.md
:white_check_mark:Succeeded
View

Community/team-site-or-communication-site.md
:white_check_mark:Succeeded
View

Community/versioning-basics-best-practices.md
:white_check_mark:Succeeded
View

Community/what-is-content-type.md
:white_check_mark:Succeeded
View

Community/what-is-site-column.md
:white_check_mark:Succeeded
View

Community/working-with-modern-clientside-pages-using-pnp-powershell.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Cleanup unused stuff in ssl local.h

This pull request is ready to merge

Merged to the master branch. Thank you for your contribution.


Using custom classes for theme customization

I am using Tailwind CSS for my project and it would be great if I could use it with this component too. Instead of color codes it would be great if I can add custom classes to the different parts of the table. This way paddings, margins etc. can also be modified easily.
Is there any way I can achieve that?

As an example the Element Plus table has the following properties:

row-class-name
cell-class-name
header-row-class-name
header-cell-class-name
table-class-name etc.

As an example the Element Plus table has the following properties:
row-class-name
cell-class-name
header-row-class-name
header-cell-class-name
table-class-name etc.

Thank you for the advice, I will add class-name properties in the next version by referring to the Element Plus table

@feAnnamari  I have released class name customization feature and now you can add class names of Tailwind CSS into table, header, header item, body row and body item. But please keep in mind that the CSS code of Tailwind CSS may conflict with the CSS code of vue3-easy-data-table, At that time, you have to write your own CSS code, you can use Style customization feature which is based on CSS variables or even write your own CSS code with !important.


Added the background image for the three files and fixed the issue.

ISSUE #220
fixes #

Describe the changes you've made
As I was assigned with the task of modifying the login portal , forgot password and the sign up portal but the background  image was not showing up so I noticed that due to some reasons or the other the background image was not pushed into the image directory I fetched upstream to bring the updated webpage and made the necesssary changes and again pushed the necessary files(including the image) this time.
Describe if there is any unusual behaviour of your code(Write NA if there isn't)
NA
Additional context (OPTIONAL)
Screenshots of the three pages are as follows:

Test plan (OPTIONAL)
A good test plan should give instructions that someone else can easily follow.
How someone can test your code?
Checklist

[ ] I have added my name in the contributors list at the end of README.md file.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[ ] The title of my pull request is a short description of the requested changes.
[ ] Open Source Program names(OPTIONAL: If you participated in any open-source program then please mention the program name here)

@Swarga-codes thanks for pr please can you provide a test deployment link so that we can test changes.

@Swarga-codes thanks for pr please can you provide a test deployment link so that we can test changes.

Sure! Check this link: https://swarga-codes.github.io/Voters-Registration-Portal/

@Swarga-codes please make UI symmteric you can observe in ss that footer of the login container has some extra padding also please do not add border radius.

you add border radius in all the three pages i will suggest you to remove it

Image not properly aligned on all pages.

Show password feature not working in login.html.

Image not properly aligned on all pages.

Show password feature not working in login.html.

I worked only with the CSS didn't make any changes to any function.

@Swarga-codes  see the difference.
Something must be wrong in your code.
https://qazimaazarshad.github.io/Voters-Registration-Portal/login.html

https://swarga-codes.github.io/Voters-Registration-Portal/login.html

@Swarga-codes see the difference.
Something must be wrong in your code.
https://qazimaazarshad.github.io/Voters-Registration-Portal/login.html

https://swarga-codes.github.io/Voters-Registration-Portal/login.html

You can check out I fixed that show password thing and as mentioned by @nlok5923 I removed the border radius from all the three forms and tried to adjust the background image as much as possible. Sir you can check it out @QAZIMAAZARSHAD .

Will review soon.

https://swarga-codes.github.io/Voters-Registration-Portal/login.html
https://swarga-codes.github.io/Voters-Registration-Portal/forgetPass.html
https://swarga-codes.github.io/Voters-Registration-Portal/sign-up.html
@Swarga-codes check these pages!!!


Consume repo-infra boilerplate verify script

NOTE: This must be merged, not squashed
Add a subtree at repo-infra for the kubernetes/repo-infra, and begin consuming the boilerplate script from that repository and invoking it during make verify.

couple of questions:
1 - what's the diff between squash and merge?
2 - is this using any git feature or pull in the code? It looks like its a copy, so I'm wondering why its not under 'vendor' which would allow us to automagically pull in the right version by just twiddling some version string and letting glide do its magic.

@duglin

I basically mean we should not squash this into a single commit
It uses git subtree.; glide can't do this for us because glide works on go packages and shouldn't pull in things like shell files etc

I didn't realize, actually, that vendor now appears to contain all of the repo content for dependencies.  I'm open re-assessing in a follow-up whether we should use vendor/, but would like this to go in as-is for now.

yea, that's why I was confused - it just seemed like repo-infra should be treated like any other repo we pull in and use.

I'd rather use vendor than a subtree but I want this to go in for now so we don't have more issues creep in.

I tried to read the docs on subtrees but it wasn't much help so let me ask my questions here:

it appears that after this is merged there's nothing in the src tree to tell a dev that a particular dir is a subtree dir instead of just a normal dir, is that correct?
if I change something in a subtree dir and we merge it into our repo I assume it stays in our repo and not in the source subtree repo, right? Did we just fork it?
from both questions above, if we have a lot of subtree dirs in our repo how can a dev know they're not supposed to touch a file in those dirs?  With the vendoring approach its clear, its under 'vendor'.
how do we know what commit from the subtree we picked up? I suspect we have to go to the history of the subtree dir in our repo and make sure someone mentioned the commit hash in their commit msg? Or does git track this?
what's the advantage of this over just vendoring things?  It kind of feels like another "vendoring" type of approach - but w/o the built-in audit trail/warnings.  Also, it would have the vendored code checked into our repo - which is good or bad depending on your POV.  :-)

This might be a good topic for one of our calls - unless its easy to explain via PR comments.

btw - CI is failing, we can't merge until that's fixed

@duglin answers inline:

it appears that after this is merged there's nothing in the src tree to tell a dev that a particular dir is a subtree dir instead of just a normal dir, is that correct?

that is correct

if I change something in a subtree dir and we merge it into our repo I assume it stays in our repo and not in the source subtree repo, right? Did we just fork it?

I don't really understand this question, so I'll lay out two scenarios:

We change a file in a subtree-d dir inside this repo: the functionality stays in this repo until the next time we run git subtree pull ...
We change a file in the upstream repo: the functionality doesn't go into this repo until the next time we run git subtree pull ...

from both questions above, if we have a lot of subtree dirs in our repo how can a dev know they're not supposed to touch a file in those dirs?

A dev doesn't know just by looking at code that they're not supposed to touch a file in those dirs. For now, we'll have to rely on humans to catch that mistake in reviews. This will get better

With the vendoring approach its clear, its under 'vendor'. how do we know what commit from the subtree we picked up? I suspect we have to go to the history of the subtree dir in our repo and make sure someone mentioned the commit hash in their commit msg? Or does git track this?

I believe one can check the commits for a subtree with git subtree list. I'm not 100% sure about this though.
If we're missing this feature, I don't think we have an ideal solution right now, but we should iterate inside the repo-infra repo to get there.

what's the advantage of this over just vendoring things? It kind of feels like another "vendoring" type of approach - but w/o the built-in audit trail/warnings. Also, it would have the vendored code checked into our repo - which is good or bad depending on your POV. :-)

vendoring Go code would work for this, and give you the audit trail/warnings for sure, but note that it's just an implementation detail of glide (and some other Go vendoring tools) to git clone the entire repo. We shouldn't build a long-term solution that relies on that behavior, unfortunately, but I'm open to exploring it for now. I believe @pmorie is gonna create an issue in kubernetes/repo-infra to track that investigation

@arschles thanks for the answers. It kind of confirms my concerns.... it doesn't actually provide any benefit over vendoring - in fact makes it more complex and risky because, as you said, it relies on humans to remember which dirs are subtree and which are not.  Additionally, as @pmorie said, it also requires people to remember to "merge" not "squash" PRs like this.  Again, very error prone.
But ultimately it makes little sense to me to have 2 ways of vendoring in code - let's just pick one and use that for everything.

Good points @duglin. I think we should ultimately pick one and use it for everything, but I think in this case it's more important to get this working infrastructure code in -- even if the method by which we do that is suboptimal -- than hold up our progress right now.
How about a compromise for now:

We clearly document which dirs are subtrees
We remain vigilant in reviews for now
We add an issue in kubernetes/repo-infra to come up with a better solution (I'm still open to using the vendor dir for now) -- something that @pmorie is already gonna do, and people outside of this SIG can help with

@duglin

Additionally, as @pmorie said, it also requires people to remember to "merge" not "squash" PRs like this. Again, very error prone.

Merging is actually the model that I prefer, strongly, to squashing everything in a PR.  I think the author should have discretion on whether a change is a single or multiple commits.  I think authors should also have the maturity to recognize when additional commits do not add value (for example, commits you made to rebase or commits that are feedback on a PR have no value in master).

Closing this, this is @duglin's reponsibility to figure out now


Gnome kick me out like log out

Describe the bug
I am using my laptop normally, playing games, or vscode, or just browsing the internet, and than suddenly I found my laptop in log out screen. Every app was closed, not saved work.
Everything is default, not additional apps or tweaks
What did you expect to happen?
Not to close all my apps
Output of rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest
                   Digest: sha256:9949217976c012c27e58c94166daeb252d6652c4806917d81d43e6bb5b448f9f
                  Version: 39.20240331.0 (2024-03-31T17:12:02Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest
                   Digest: sha256:f613505f2d1f1686aa05d1739475336c82b6610bcd60f2cfee0da889792fc6b5
                  Version: 39.20240330.0 (2024-03-30T16:51:42Z)

Extra information or context
No response

Did this happen when the lock screen appeared?
If so, you can try adding the following environment variable (I place this in ~/.config/environment.d/mutter.conf - make it if not present) MUTTER_DEBUG_KMS_THREAD_TYPE=user

Did this happen when the lock screen appeared?
If so, you can try adding the following environment variable (I place this in ~/.config/environment.d/mutter.conf - make it if not present) MUTTER_DEBUG_KMS_THREAD_TYPE=user

Yes, it happens and then the lock screen appears.
It is not happening always, I mean every day.

Try adding the environment variable and see if the behavior still exists.

Are you still experiencing this issue?

Are you still experiencing this issue?

Hi, sorry for not replying. It didn't happen after that trick.

Also i noticed on F40 that folder environment.d is not there anymore.
There is just environment file in /etc with  MUTTER_DEBUG_FORCE_KMS_MODE=simple

Did you put it in /etc or in ~/.config?

Did you put it in /etc or in ~/.config?

now it is in ~/.config? :)


Is it possible to host MVC 6 app as Mobile App?

ASP.NET Core is on the backlog, but not available yet.


Add auto-generated SPIR-V parsing

Changelog
Remove this line, as the spirv crate isn't a dependency anymore:
spirv_headers 1.5 > spirv 0.2 (crate was renamed and reversioned)

Add:
- Added a `spirv` module to the main crate, which contains an auto-generated parser for SPIR-V files, and various other utilities that can be used to analyze shaders at runtime.

This PR adds SPIR-V parsing types and functions, auto-generated from the SPIR-V grammar document, which is included. The grammar is a JSON document, so this adds serde_json as a build-dependency for parsing. Some of the code has been moved from Vulkano-shaders and reworked. In particular, any parse errors that are reported will include information on the affected instruction, where the error happened, and the SPIR-V words of the instruction for debugging.
This is still a draft; the main parsing feature is now done, but I want to add code to gather some additional data from the module after it's parsed. Vulkano-shaders is also a bit of a mess, because it's only haphazardly converted to the new version. That needs to be fixed up too.

but I plan to add code to ShaderModule that automatically parses the binary at runtime

@Rua Then it probably would require transferring of Shaderc dependency, the most heavyweight dependency in the entire project, to Vulkano crate too. Which is maybe not that big deal as most of the users already use on Vulkano-shaders anyway(but not all, some use 3rd party tools e.g. RustGPU). I suggest to do so by introducing Crate feature.
If you want to work on advancing Shader generation system even further you can think of migrating from Shaderc to something native to Rust, for example to Naga.

Shaderc is used for compiling the code, while the rest of Vulkano-shaders analyses the compiled code and generates Rust types and other things. I have no intention of moving the compilation over to the main crate, I'm not sure if that's even feasible. Only some of the code analysis will be moved over, because it's useful for shaders that aren't loaded via Vulkano-shaders too. Compilation and the generation of Rust structures will remain where it is.

@Rua Excellent work! As always! Thank you, Rua. :) PR merged.


GROBID citation parsing issues, for possible training

I have recently started using the parseCitationList endpoint to parse raw citation strings from the Crossref citation metadata, included in the Crossref API and bulk metadata dumps. Many citations are already parsed and/or matched to specific DOIs, either by the original publisher or by Crossref themselves. My goal is to do additional parsing and matching, especially to works which do not have DOIs (like arxiv pre-prints, conference proceedings, books, etc). This initial batch are mostly English language references, to English language works. Overall, GROBID is working really well for this task.
When doing hand evaluations, I took notes on some issues parsing with GROBID, and they are available here: https://gist.github.com/bnewbold/b437e363e6a0429719c65c751babe84d
Some of the challenges here are issues with the citation strings themselves (like OCR problems). Some of them I suspect are due to missing entries in the grobid-home lexicon lists (like non-European author surnames). And some are corner cases not parsed well (yet).
If I manually tag a subset of these in TEI-XML, and submit a MR to include them as training data in ./grobid-trainer/resources/dataset/citation/corpus/ and/or grobid-trainer/resources/dataset/name/citation/corpus, would that be a helpful contribution to the project, or would it just create a bunch of review work?

Thank you @bnewbold , this is such a great effort and so useful !
This is exactly what is needed to improve Grobid, there are many citation patterns missing from the current training data.
You are very welcome to manually label some examples corresponding to the cases you identified. We might want to improve the annotation guideline for the citation model for the cases not covered. In any case, any annotations are reviewed (because two pairs of eyes are always better), but it's not a problem.

I took a first pass at annotating these: https://github.com/kermitt2/grobid/pull/854


Sortable tables

How to use sortable tables? Can you please add samples/documentation for it?

Good question - I'll work with the team to see what we can do.

Since Fabric is currently focused on styling, we're looking into what "sorting" would look like for the table. Adding richer table interactions aren't immediately on our roadmap, but we'll leave this open so we can be sure to track it as the project grows.

Styles for tables with sort options is what I was looking for. I would like to highlight the column header of the table by which it is sorted along with the sort direction indicator.
A JS for doing client side sorting would be a valuable component but the styles for implementing table with sort is common requirement with any table implementation.

Any ideas or recommendations on this from the team?

Unfortunately, not yet. We'll comment back if there are any updates.

This is actually on the plans for the table that we're building in the angular directives we're working on. Hope to have a initial release of a few directives in the first drop... sortable tables won't be in it, but it's definitely in the plans: ngofficeuifabric.com.

We have sortable table now with the htto://ngofficeuifabric.com. You can grab our library from npm, bower or nuget.
You can see it in action here:
htto://ngofficeuifabric.com/demos/uifTable

We'll need some design review before adding this to Fabric.

To start with, we're going to add a style for the header of a column that is sorted. We're working with design now to make sure we have this right. In future updates we may add JavaScript support for sorting columns.

Hi all, has row sorting been added to office ui fabric? i need to add row sorting to my office ui fabric table

@johnnyongesa Sorting isn't in the Office UI Fabric component… there isn’t functionality per-say within the components.
However the Angular port of Office UI Fabric, ngOfficeUiFabric does have column sorting as well as selectable rows in the table implementation. Check out a demo here: http://ngofficeuifabric.com/demos/uifTable/

The functionality of sorting rows is not yet in Fabric, and is not planned for inclusion in the upcoming 3.0 release. However, we are going to release TypeScript for table component (to allow for selection of rows) and this could be extended to add sorting. As Eric mentioned above, we just need to get official designs for how sortable tables should look before adding it to Fabric.

Home you consider sorting in next releases, this is a very important component of table component and almost every user of table component uses sorting

@mikewheaton will the TypeScript additions that you are "releasing" also going to be in the CDN releases or like they are today where only CSS is in the CDN but JS is something you have to add to the project?

We're finally going to start hosting all of the JS on the CDN, so that functional components can be added to an app without any downloading or local building of the project. 😄

@johnnyongesa - we'll make a note for the work item on our end.

Great news… will the time from a release to getting it up on the CDN shorten as well? Right now looks like it’s a 2 month + delay from a new release to it showing up on the CDN.

Well, it can't get any worse. We're working with the CDN team on a new process that should allow us to push through a new version in 1 to 2 weeks. Stay tuned.

Hi guys, is there a way to re-size the ms-Dialog component? i would want to increase the width of ms-Dialog compoenent

@johnnyongesa: Please open a new issue next time, so we can keep each issue on topic. 😄  Here is a quick demo of overriding the max-width value of ms-Dialog-main to change the width of the dialog.

Thank you mike for the response, but the link you shared does not give any idea of what to do. It just has a html file with  tag and a blank css file

@johnnyongesa: I've opened a new issue for this and posted a more detailed response there.

There are no plans to update the current Table component with sortable columns. We will, however, be adding a new details list component that will include this functionality. This is now included in our roadmap.


Define ordering of two inlay hints with the same position

I have a case where I'm producing two InlayHints for the same position.
One hint is parameter names:
// gets a Parameter hint of the name "bar"
// foo(bar: a);
//     ^^^^
foo(a);

And one is inferred types for list literals:
foo(
  // gets a parameter hint of the list type
  // children: <String>[objA, objB],
  //           ^^^^^^^^
  children: [objA, objB],
);

When these two things happen to occur together, we'll produce both kinds of hints at the same offset. We can't combine them because InlayHintLabelParts don't have kinds, only InlayHints to:
// foo(bar: <String>[objA, objB]);
//     ^^^^ ^^^^^^^^
foo([objA, objB]);

VS Code appears to be showing these hints in the order they appear in the results, but I think this should be defined so that servers can rely on it without worrying that it's undefined and might change (or be different across clients).

@dbaeumer if this is not controversial, I can send a PR that tweaks the text to state this.

I think it is fair to state that the should appear in the order in which they are defined. @jrieken any objection from your end. I think  specifying this would make sense in vscode.d.ts as well.

@dbaeumer thanks, I've opened:

https://github.com/microsoft/language-server-protocol/pull/1681
https://github.com/microsoft/vscode-languageserver-node/pull/1197

@dbaeumer @jrieken any feedback on the PRs linked above?
(It's not urgent, I'm currently just assuming this is going to stay consistent, but it'd be good to have in the spec :-) )

I was waiting for having it in VS Code first.

Makes sense, though I'm not sure if I need to do anything more - the VS Code PR hasn't had any feedback yet.


setState() will trigger own state reset when using react-router?

 I'm facing a most trouble when using react-router. I have develop a simple react app including using react-router, which have a simple setState() function as a props and pass to child component. But when child component trigger this function which will also reset the own state to default value. I dont know how the problem trigger, because when I simply just call child component with function without react-router it will not reset the own state. Here is my code:
App.js
import React, { Component } from 'react';
import User from './User'
import { BrowserRouter as Router, Route, Link, Switch } from "react-router-dom";

class App extends Component {
	constructor(props) {
		super(props);
		this.state = {
			name: ''
		};
	}

	handle = () => {
		this.setState({name: 'apple'})
	}

  render() {
    return (

		<Router>
		<>
		<Link to="/me" >Me</Link>
		<Route exact path="/me" component={() => <User handle={this.handle} />} />
		</>
		</Router>

    );
  }
}

User.js
class Users extends Component {
	constructor(props) {
		super(props);
		this.state = {
			type: ''
		};
	}

	handleClick = () => {
		this.setState({type: 'orange'}) // this line i have setState type to 'orange' before calling the parent function.
		this.props.handle() // this line is just to change the parent state by using handle()
		console.log(this.state) // this line is just print the own state.
	}

  render() {
    return (

Click!

    );
  }
}

-Response:
{name: "apple"}
{type: ""} => but is should be "orange" not empty.

Could anyone can help me? Thanks.

<Route exact path="/me" component={() => <User handle={this.handle} />} />

Please see the second paragrpah of the <Route children> docs.
For future support questions, please use either StackOverflow or the Reactiflux Discord. Both of those are setup to answer support questions, while the issues sections here is intended for bug reports. Thanks!