Fix variable name in awk -- s/time/tm/
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 9 2024
Jan 20 2024
Jan 19 2024
Advertise -j option in stats usage statement
Oct 22 2023
Oct 17 2023
Full context as-requested by emaste
In D42242#963650, @emaste wrote:FYI for future Phabricator uploads please include full context, e.g. git show -U99999 <hash>. Details are at https://wiki.freebsd.org/action/show/Phabricator
Oct 16 2023
Sep 1 2022
LGTM
Aug 27 2022
Bump port to 1.2 so we catch latest development (the inclusion of a dashboard for the Block I/O stats)
Fix distinfo
Update diff before applying to head
I was working on committing this and went to go apply the patch to the tree and the patch no longer applies cleanly.
Aug 23 2022
Add missing dashboard examples from 1.1
Fixup package COMMENT to match what I have set for 1.1
Pepper [@]sample
In D36051#824457, @woodsb02 wrote:You’re probably already aware, but ports has a commit hook so that commit messages should start the first line with “category/portname: description”.
So commit message should have first line:
sysutils/dwatch-json: update to 1.1, restore maintainership
Aug 22 2022
Reclaim
Tested and ready for re-review
Add missing io-sample conf
makesum for 1.1
Add symbolic link entries from 1.1
Add missing config to plist for 1.1
Update pkg-descr for 1.1
Update the plist for 1.1
Abandon the update to 0.5 and update to 1.1
Aug 16 2022
Great work. I gave it a thorough check, inside and out. Green-lit to go.
Aug 6 2022
From my 2018 BSDCAN presentation slides, here are the modules in base ... we're not going to add "dwatch-" prefix to all those simply because a PORT convention says that a PORT should install files named the same as the PORT when the PORT should follow BASE convention already set forth 6 years ago
In D36051#818573, @diizzy wrote:I discussed this submission with dteske on IRC and possibly have a few suggestions:
PORTNAME should correspond to the naming convention of installed files and usecase whenever possible, so dwatch-json --> dwatch-json-net and preferably libexec/dwatch/json-net* --> libexec/dwatch/dwatch-json-net*
Grafnet should be broken out, put in a separate port and be set as a dependency (if required) as it doesn't seem to be a hard requirement and/or limited to dwatch-json-net looking at pkg-descr
Aug 5 2022
Jul 1 2022
I have two suggestions, but you're only meant to pick one. I don't care which. Minor optimization or major optimization.
Jun 29 2022
Sorry for being late to the party
Jun 2 2022
There we go. This looks to be all good.
Jun 1 2022
The raw diff [1] looks funny. The "before" (line removed) doesn't match what is in head [2].
May 31 2022
In D35357#801773, @brd wrote:In D35357#801606, @dteske wrote:Can we discuss perhaps using K&R style naming?
That is to say, BSDINSTALL_SKIP_* instead of BSDINSTALL_*_SKIP -- it would go a long way to being able to more-easily grep-out the skippable options and also open the prefix to being used in other parts of bsdinstall that are unrelated (read: other scripts/functions)
I was thinking in a follow up commit about adding more variables, BSDINSTALL_TIME_NAME and BSDINSTALL_TIME_DESC to populate the menu in finalconfig(). Doing it that way seemed a bit nicer to me, but I don't feel strongly about it. So instead we could use BSDINSTALL_SKIP_*, BSDINSTALL_NAME_* and BSDINSTALL_DESC_*.
May 30 2022
Can we discuss perhaps using K&R style naming?
I will also note that the removal of the "export" may cause issues. There would be other acceptable solutions, such as:
Changes required.
May 28 2022
In D35331#801282, @asomers wrote:Oh, sorry about that. I'll commit the fix. I didn't even realize that it was possible to leak memory in sh.
May 27 2022
Fix a memory leak introduced by previous commit.
This is not what I wanted. The second diff (that I prematurely accepted) that you committed omits the f_isset call
Do you need me to commit this or do you have a venue/access?
May 26 2022
Looks good
The change to use f_isset in 2 places is a good one, thank you. However, I have issue with the removal of the call to "local" above the second hunk.
Apr 18 2022
This looks pretty well thought out. Give me some time to review it and get back to you. Thank you for your efforts.
Oct 9 2021
In D16132#711222, @pstef wrote:Looks good to me.
I'm playing with this utility on my stable/13 and I like the idea very much. It feels unixy to me in that the tool is abstract enough for me to apply it to various problems which may be difficult to define beforehand. But I can already see myself using this instead of generating permutations with recursive CTEs in SQL like I sometimes do.
Also, although I'm not sure anyone will find this meaningful, cmb reminds me of a problem I was solving recently at job, feeding a Cassandra table random data:
The table and its keyspace were defined as follows:
CREATE KEYSPACE test WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };
CREATE TABLE test.base(part text, ord text, fill text, PRIMARY KEY((part), ord));We feed the table like this:
# base32 -w 2000 < /dev/urandom | cut -b1-3,4-8,9- --output-delimiter=, | cqlsh -u $CASS_USER -e 'COPY test.base FROM STDIN'Cutting base32 output into columns of arbitrary length gives us control over cardinality of each column; specifically we want to know the upper bound on the number of partitions and the number of rows in each partition. Given a set of k (32 in base32) characters, the number of n-tuples (n characters in a column) is k^n. For example, taking the first 3 letters of each line to use in the partitioning column gives us the upper bound of 32^3 partitions, which is 32768.
Forgive the verbosity and being Ubuntu-specific (base32, cut --output-delimiter, /dev/urandom), but I hope you get the idea: I tend to use unix tools when interacting with other tools or services, databases especially.
By the way, the util and the library seem small enough:
-r-xr-xr-x 1 root wheel 46K Aug 5 14:17 /usr/bin/indent -r--r--r-- 1 root wheel 21K Aug 15 17:49 /usr/lib/libcmb.so.0 -r-xr-xr-x 1 root wheel 31K Aug 15 17:50 /usr/bin/cmb
In D16132#626980, @gbe wrote:LGTM for the man page related things.
In D16132#565399, @markj wrote:In D16132#564913, @dteske wrote:Hi markj,
Yes, it was suggested that I make a port first.
However, everybody seems to be ignoring what I am saying regarding the utility of this tool being equitable to seq, jot, and friends.
Just yesterday, I did the following:
cmb -d / {a..z} | xargs stat 2>&1 | dpv -l -The purpose was to generate millions of stat errors so that I could work on some filesystem patches to improve the performance of stat in nfsd.
Could I have used jot? Maybe, but it would have been more difficult.
Could I have used seq? Maybe, but same problems as jot. I needed discretely unique test matter.I have been ignoring the suggestion to put it into ports because not one single person has even addressed the use-cases for base.
How would one make an argument for jot or seq being in base? If you pretend that they are not in base, what arguments would you use to introduce them?
cmb is kind of like that -- it has a million uses. Asking why we should have it in base is kind of like asking why we should have bc in base.
cmb is a math tool. A very powerful tool that fills a myriad requirements, not to mention the following use-case which I will once-again reiterate that has once again been ignored ...
I don't care about the build option survey. It was an example.
I care about using this for combinatoric combination of ports given various options.
Let's talk about dialog4ports -- a tool that lives in ports that is required by ports. So many times this has caused me headaches and I really don't want to go down that road. It is very frustrating when you get into a situation where ports needs X from ports but you can't compile it because your base and ports frameworks have diverged so you then have to devolve into first updating your base shared Mk files relied-on by ports. It's real shit-show.
Putting cmb in base will allow it to:
a. solve math problems
b. allow me to work on base enhancements with only base (think Filesystem debugging, filesystem optimizations, memory testing, scheduler profiling, etc.)
c. be usable by ports without being stuck in the quagmire-catch-22 described aboveRegarding the prior discussion, I just see that the original thread on -announce appears to end with you saying that you would make a port. That didn't happen, and since there was some objection to putting cmb and libcmb straight into the base system, we should make sure that those objections won't be raised again after a commit. The right way to do that is to follow up on the lists, like -hackers and -arch, since only a small handful of developers are subscribed to this review.
I understand that cmb is intended to be a general-purpose utility, but that alone is not sufficient for putting it in the base system. jot(1) and seq(1) make for an interesting comparison since seq's functionality is a subset of jot's; seq was added to the base system relatively recently, specifically to make us more compatible with other unix environments. jot predates FreeBSD and comes from a time where a batteries-included approach to shipping an OS was more important than it is today.
I personally think that cmb would be an interesting addition to the base system, but there should be some concrete justification for it to be there. The build option survey is not really a compelling example. A ports target that builds a port with all possible combinations of options seems useful, but is there currently some work in progress to implement that? I understand that having the ports framework depend on a port is painful, but unless the absence of cmb from the base system is currently blocking a useful project, I don't see why this is a strong argument for not making a cmb port. You've written a number of large sh-based components of the base system - could any of them make use of cmb? My point is just that I believe that you could successfully argue for cmb's inclusion in the base system, but the idea first needs to be socialized more fully. A port is a reasonable alternative in the meantime and will make it easy for others to try using cmb.
Oct 8 2021
Sep 22 2021
In D25711#616156, @dteske wrote:Just a simple bogon in the src bits, after which I will approve
May 10 2021
Dec 11 2020
Just a simple bogon in the src bits, after which I will approve
Aug 3 2020
Thank for submitting. Give me a chance to review, but I do believe this looks like a good candidate for commit. Thank you
Sorry for the delay, had a disk failure take out my operations for a full 4 weeks, but finally got all the data recovered and back up and running
Jul 3 2020
Hi markj,
Jun 20 2020
I've only a couple changes I'll make before committing with reference to OP. Instead of "doclose" I will use "opened" which makes the code easier to read.
May 26 2020
I'm going to set an ETIMEOUT of 30 days. If there is no objection, I will import to base HEAD.
May 20 2020
Indentation fixes. Fix whitespace for consistency. Fix >80c lines.
Pre-update commandeer
Apr 30 2020
LGTM