I feel silly asking this.. but its doing my head..
if I use 'https://maps.googleapis.com/maps/api/place/autocomplete/json' and set the input parameter to say - 'Palazzo Cast' I will get about 5 suggestions - none of which will be the one I'm looking for. if I set input to 'Palazzo Castellania' I will get zero results - even though there is a place called this (see below). I've set the region parameter to 'mt'...
If I use 'https://maps.googleapis.com/maps/api/place/findplacefromtext' and set the input parameter to 'Palazzo Castellania' - I will get 'the Ministry of Health' - which is correct - however, if I put a partial string in I'll get only a single candidate which will be something different - there doesn't seem to be a way to get multiple place candidates?
I'm guessing from an API side - I have to do a multi-step process - but it would be good to get some input.
My thoughts:
I start with 'https://maps.googleapis.com/maps/api/place/autocomplete/json' - if I get an empty result, I try 'https://maps.googleapis.com/maps/api/place/findplacefromtext'
if I get a single result from either then I can pass the placeID to the places API to get more detailed data.
Make sense? It feels argly..
Edit
So watching how https://www.google.com.mt/ does it... while typing it uses suggest (and never gives the right answer, just like the API) and then when I hit enter it uses search and gives the correct answer... leading me to the conclusion that there is actually two databases happening!
Basically "its by design".. there is no fix as of Feb 2023.. My thoughts are to cache results and do a first search against that otherwise I'll probably use bing or here
This is a simple git repository. I have tagged the commits with numbers for easy referencing. The repo has the following branches:
master: 13 commits (1,2,3,4,5,6,7,8,9,10,11,12,13)
new_branch: 8 commits (1,2,3,4,5,6,14,15)
test_branch: 3 commits (1,2,3)
yet_another_branch: 14 commits (1,2,3,4,5,6,7,8,9,10,11,12,16,17)
Commit 5,6 belong to a pull request thus the blue portion with 5,6 is not a branch.
Please note that commit 1,2 are considered as part of all branches, but I want to consider all black colored commits as part of the master. Similarly, for 'test-branch', I want to consider only commit 3 as part of the branch.
from git import Repo
git_url = "https://github.com/unimamun/test-repo.git"
repo_dir = "/mnt/hdd/aam/J2_Repos/test-repo/test-repo"
repo = Repo.clone_from(git_url, repo_dir)
# get all commits by branches
def get_commits(repo, ref_name):
commits = []
for commit in repo.iter_commits(rev=ref_name):
commits.append(commit)
return commits
print('\nCommits in Branches:')
for ref in repo.references:
print(ref.name,': ', str(len(get_commits(repo, ref.name))))
print('\nCommits in master:')
commits = list(repo.iter_commits('master'))
commits.reverse()
i = 0
for commit in commits:
i += 1
print(i,': ', commit.hexsha)
# to see parents of the commit
#print('Parents: ',commit.parents)
From the above code, I have the following output:
Commits in Branches:
master : 13
origin/HEAD : 13
origin/master : 13
origin/new_branch : 8
origin/test-branch : 3
origin/yet_another_branch : 14
Commits in master:
1 : 694df9fee2f9c03a33979725e76a484bce1738a0
2 : c0fe1b76131b7fcb103f171fd93d85cda17b756c
3 : 0199ad335f65d52a2895a678a19e209e1e16a1a7
4 : dd0903259b0aadbf2d8fb00e566eee014264f7c0
5 : 7ed55c51e2527f47bc6344cd960ff5beb90cc65d
6 : d10f19c85fbc1c27b7719a2dc64989255697181d
7 : c41bdfaeae1f801776420ce161ca2555dffc5aad
8 : 56b5d6e1831a477c79e0fd336acc96ca266d5dea
9 : 6305a72d4e257ebe74b10ca538906f1eceb091bf
10 : 4c5d1ebe5f2f8168ee8bf4a969855821d04caf09
11 : 362bc52be00af3fb917196cf27a8ddc0bb8fd4ba
12 : 5a70a46394eb08b4b48f9eb05798048ca7269a9d
13 : f4a8bdd318b2678191d06616a55df26416a28363
I want the following output. So that 'master' is printed for every black dots in the figure and other branch names for non-black color commits (in this case for green colored commit 3, test-branch should be printed)
Commits in master:
1 : 694df9fee2f9c03a33979725e76a484bce1738a0 master
2 : c0fe1b76131b7fcb103f171fd93d85cda17b756c master
3 : 0199ad335f65d52a2895a678a19e209e1e16a1a7 test-branch
4 : dd0903259b0aadbf2d8fb00e566eee014264f7c0 master
5 : 7ed55c51e2527f47bc6344cd960ff5beb90cc65d master
6 : d10f19c85fbc1c27b7719a2dc64989255697181d master
7 : c41bdfaeae1f801776420ce161ca2555dffc5aad master
8 : 56b5d6e1831a477c79e0fd336acc96ca266d5dea master
9 : 6305a72d4e257ebe74b10ca538906f1eceb091bf master
10 : 4c5d1ebe5f2f8168ee8bf4a969855821d04caf09 master
11 : 362bc52be00af3fb917196cf27a8ddc0bb8fd4ba master
12 : 5a70a46394eb08b4b48f9eb05798048ca7269a9d master
13 : f4a8bdd318b2678191d06616a55df26416a28363 master
I need to iterate from commit 1 to 13 and along the way I need to determine which commit belong to which branch. Thanks a lot.
As you note:
commit 1,2 are considered as part of all branches
That is, the set of reachable commits from any given branch, as determined by starting at the branch tip commit and working backwards through the Directed Acyclic Graph of commits, always includes commits 1 and 2.
but I want to consider all black colored commits as part of the master [branch]
In that case, start by finding the graph of all commits. As you probably know, a graph is defined as G = (V, E) where V is the set of all vertices and E is the set of all edges. Git stores the vertex and edge data together, in a commit: the commit's identity is its hash ID and its edges—outgoing arcs, really, since this is a directed graph—are its parent commit hash IDs.
Next, use the name you wish to designate as the "most important" branch (i.e., master) to find the hash ID of its tip commit. Assign this commit to the master set. Walk the reachable portion of the graph, starting from this commit, adding each commit to the set of commits in master.
Now, for each remaining branch—in some order, and this order will determine your results in many cases, so you may wish to use a topological sort—start at the tip of the branch and walk the reachable portion of the graph:
For any commit that is already assigned to some branch, ignore it—and you can immediately stop walking the graph at this point since all its predecessors will, by definition, be assigned to some branch.
The set of commits you reached during this walk is the set of commits you wish to claim "belong to" this branch.
There are multiple ways to implement this, including walking a subgraph determined by set-subtraction: simply subtract each branch's subgraph from the original G.
If it's more convenient—it may well be, since you won't have to find G—you can do this in the other direction: start with master and find reachable commits that are not in some set that's initially empty. Add each commit to the set, while listing them as "in master". Then iterate through the remaining branches: if a commit is in the set-so-far it has already been claimed, else it gets claimed by this branch. The problem with working this way is that you might pick some branch (feature-X) that contains all commits that are contained by some other branch (develop) before picking the smaller branch (develop): you cannot do a topological sort without the full graph.
Once you have done this for all branch tips, you have now assigned each reachable-from-a-branch-tip commit to a single branch (instead of, as Git does, assigning it to every branch from which it is reachable).
Note that there may exist commits in the Git graph that are not reachable from any branch tip (e.g., are reachable from a tag but not from a branch). If you dig into the internals of Git, you can find commits that are reachable only from reflog entries, or even some that are completely unreachable, discoverable only by iterating through the entire object key-value database. The latter is essentially what git gc does: walk the database to find all objects, then do a mark-and-sweep garbage collection operation, much like Lisp would do, retaining reachable objects and discarding the unreachable ones.
You probably want to try the "--first-parent" option:
git log --oneline --first-parent master
Mathematically speaking, this is a graph, which makes that at merge point, no branch is supposed to be "more important" than the other one. But in the facts, the problem always raises and when performing a "merge" operation, one actually "brings" an external branch into the current one. This current branch is therefore stated as the first one inside the commit object.
If you try this on the master branch of a large project such as the linux kernel, you'll mainly fall on merge points, with only a few direct changesets on the branch.
And if this is precisely what you want to know about, you can additionally specify "--no-merges" to explicitly exclude merge points.
git --oneline --first-parent --no-merges master
This, for instance, would exclude points 4 and 7 from your graph.
Finally, to restrict a search to commits that only belongs to a specific branch and that are not inherited from the master one, use the ".." operator:
git log master..yourbranch
… would only show commits that are reachable from "yourbranch" but NOT from "master".
So I have a google sheet dataset. Great! Using filter() to run a few reports off of it. No problem.
The issue is, the end-users want to be able to put comments into the reports that have been run off, and have the main dataset update based on these comments. Additionally, as things change, the data in the reports move around. They'd like the comments they make to move around with them.
So what I initially did was created a "Comment database", which checked every report and the main dataset for comments, and pulled them in. Works like a charm.
I also included a OR(Not(Now()="Dummy") clause to the comment database aggregation to force recalculation every time a change was made.
I then enabled iterative calculations (Tried at 1, 2, and 3 iterations), and had everything be an index-match back to the comments, with the idea being that if someone entered a new comment, it would update the dataset, which would then update the main report once they dragged the formula back over.
In Excel, this would work perfectly - the iterative calculation would "store" the comment value, and it would continue to cycle through.
However, in Google sheets, this isn't working.
I've asked if the obvious solution of "Just update the main dataset whenever you want to change something" would work. For reasons unknown, the answer is no.
How can I get what I want? I'm open to using google scripts if necessary, although I'm not too familiar with the language.
As an example:
Dataset:
ID: 123
Comment: None
Report:
ID: 123
Comment: "Hello World"
Becomes:
Dataset:
ID:123
Comment:"Hello World"
Report:
ID:123
Comment:"Hello World"
The comment has moved from the report to the dataset
Then once we add ID 456:
Dataset:
ID: 123
Comment: "Hello World"
ID: 456
Comment: None
Report:
ID: 456
Comment: None
ID: 123
Comment: "Hello World"
The comment has moved down with the ID it's associated with
So it turns out I had a bad conditional statement, and fixing it fixed the problem.
This type of system will work as a two-way street for information, it's just silly convoluted.
Currently, I made a tool to rename view numbers (“Detail Number”) on a sheet based on their location on the sheet. Where this is breaking is the transactions. Im trying to do two transactions sequentially in Revit Python Shell. I also did this originally in dynamo, and that had a similar fail , so I know its something to do with transactions.
Transaction #1: Add a suffix (“-x”) to each detail number to ensure the new numbers won’t conflict (1 will be 1-x, 4 will be 4-x, etc)
Transaction #2: Change detail numbers with calculated new number based on viewport location (1-x will be 3, 4-x will be 2, etc)
Better visual explanation here: https://www.docdroid.net/EP1K9Di/161115-viewport-diagram-.pdf.html
Py File here: http://pastebin.com/7PyWA0gV
Attached is the python file, but essentially what im trying to do is:
# <---- Make unique numbers
t = Transaction(doc, 'Rename Detail Numbers')
t.Start()
for i, viewport in enumerate(viewports):
setParam(viewport, "Detail Number",getParam(viewport,"Detail Number")+"x")
t.Commit()
# <---- Do the thang
t2 = Transaction(doc, 'Rename Detail Numbers')
t2.Start()
for i, viewport in enumerate(viewports):
setParam(viewport, "Detail Number",detailViewNumberData[i])
t2.Commit()
Attached is py file
As I explained in my answer to your comment in the Revit API discussion forum, the behaviour you describe may well be caused by a need to regenerate between the transactions. The first modification does something, and the model needs to be regenerated before the modifications take full effect and are reflected in the parameter values that you query in the second transaction. You are accessing stale data. The Building Coder provides all the nitty gritty details and numerous examples on the need to regenerate.
Summary of this entire thread including both problems addressed:
http://thebuildingcoder.typepad.com/blog/2016/12/need-for-regen-and-parameter-display-name-confusion.html
So this issue actually had nothing to do with transactions or doc regeneration. I discovered (with some help :) ), that the problem lied in how I was setting/getting the parameter. "Detail Number", like a lot of parameters, has duplicate versions that share the same descriptive param Name in a viewport element.
Apparently the reason for this might be legacy issues, though im not sure. Thus, when I was trying to get/set detail number, it was somehow grabbing the incorrect read-only parameter occasionally, one that is called "VIEWER_DETAIL_NUMBER" as its builtIn Enumeration. The correct one is called "VIEWPORT_DETAIL_NUMBER". This was happening because I was trying to get the param just by passing the descriptive param name "Detail Number".Revising how i get/set parameters via builtIn enum resolved this issue. See images below.
Please see pdf for visual explanation: https://www.docdroid.net/WbAHBGj/161206-detail-number.pdf.html
In a gitlab project under issues->labels I have pressed the link to generate labels, naively assuming this would allow me generate a customised set of labels for the project. On the contrary I found myself with a set of default labels that unfortunately don't suit me, so I don't want other users to use this set, hence I want the list to disappear again.
How would I achieve that?
Many thanks.
Assuming a self-installation as recommended by Gitlab:
$ ssh your.gitlab
$ sudo su -l git
$ cd gitlab
$ bundle exec rails console production
> p = Project.where(path: 'your_project').first # ensure this is your project
> p.issues_default_label_list # examine the default list
> p.issues_default_label_list = [] # removes all defaults
> p.save
The generation is done by app/controllers/projects/labels_controller.rb, which uses:
#labels = #project.issues_labels
This is defined in app/models/project.rb
def issues_labels
#issues_labels ||= (issues_default_labels + issues.tags_on(:labels)).uniq.sort_by(&:name)
end
Those labels are defined in lib/gitlab/issues_labels.rb.
So if everything else fails, you still can change those values in that file.
class IssuesLabels
class << self
def important_labels
%w(bug critical confirmed)
end
def warning_labels
%w(documentation support)
end
def neutral_labels
%w(discussion suggestion)
end
def positive_labels
%w(feature enhancement)
end
Note that even if that list was applied when creating an issue, removing labels on said created issue is now easier with GitLab 13.5 (October 2020)
Remove issue labels with a single click
Removing a label from an issue used to require three clicks, fetching a fresh list of labels from the server, and using a search box to find the label you want to remove. This was unintuitive and inefficient, given that GitLab users remove labels from issues approximately 55,000 times per day.
It may not be revolutionary, but you can now remove an issue’s label with a single click.
See Documentation and Issue.
With GitLab 14.7 (January 2022):
Delete labels directly from the Edit Label page
In this release, we’ve added the ability to delete labels in the Edit Label page. This is a usability enhancement that finally allows users to delete labels instead of having a long list of labels called “deprecated”. This includes Admin, Project, and Group labels.
See Documentation and Issue.