Related
Using Revit API, I split a wall in 3 parts. To do that, I create 3 Lines:
Line.CreateBound(p1, p2)
Line.CreateBound(p2, p3)
Line.CreateBound(p3, p4)
Then I create a wall with each of these lines, which are consecutive and aligned. The result isn't as expected, as the third wall is overlapping the second one, see the illustration below.
Now, this could be a programming error, but I print the Lines' end points just before creating the 3 walls, and these points are perfectly consecutive, in the right order. The print looks like this (I remove the Y and Z coordinates, they're constant):
Now creating a new wall, from (11.811023622, ...) to (17.388451444, ...)
Now creating a new wall, from (17.388451444, ...) to (18.044619423, ...)
Now creating a new wall, from (18.044619423, ...) to (28.871391076, ...)
If I then use the RevitLookup Addin to check that problematic wall, I see that its LocationCurve's origin is indeed located at (18.044619423, ...).
But if I look at it's BoundingBox Min and Max properties, I can see that it starts at 17.388.. and goes up to 28.871391076. That is what the illustration shows..
Furthermore I use this split method on some other walls in my geometry, for which I have no problems, and I do obtain 3 nicely consecutive walls!
My question therefore is: Am I missing a property somewhere that would somehow 'shift' the wall BoundingBox from its Location Curve?? That would explain somehow this behavior?
How else could I explain and correct this?
Thanks a lot!
Arnaud.
Maybe Revit is automatically connecting the walls somehow, and modifying their geometry in order to connect them well. Imagine, for example, two perpendicular walls along the X and Y axis, from (0,0) to (1,0) and (0,1), respectively, with a wall thickness of 0.2. Revit will connect them. To do so, it will extend them in the corner where they meet at the origin. Due to that, their bounding boxes both do not end at (0,0) (or at (0,-0.1) and (-0.1,0)), as you might expect. Instead, they will both have a common corner at (-0.1,-0.1). Thus, both bounding boxes will have a maximal extension of 1.1 instead of 1.0. I hope this explanation is clear. A picture would say more than a thousand words... sorry about the stupid attempt using words instead.
You may be able to prevent wall 3 from joining up with wall 1 by setting the location line JoinType property on both of them to JoinType.None.
EDIT: Using WallUtils.DisallowWallJoinAtEnd function did the trick!
So this is the status after some investigation: The third wall is indeed auto-expanding its BoundaryBox so that it connects to the first wall. And doing that, it overlaps the small wall (see "wall 2 in the picture below - this wall is of different type than walls 1 and 3 (which are of same type), hence being ignored when wall 3 is looking for somewhere to connect) in between them (that was only 20cm long).
Making "Wall 2" a bit longer (40 cm) helps and prevents the 3rd wall from auto-expanding to the first wall, that is what I did here:
Then it's ok. But this doesn't solve the problem. I didn't see any way of preventing the "auto-expansion" of the BoundingBox, or any way to control the max distance at which it looks for another wall.
I also tried first imposing 3 different types, and then changing wall type of wall 3 to the same wall type as wall 1: when their wall types are different: no expansion. When I change the wall type, it expands, even though the wall was already created.
Finally, the really strange behavior is that for some walls, I don't have this problem at all. This is: 3 walls of the same types as when I do have the problem, with same length of 20cm for wall 2. This last thing is really unexplained.
I've been building a parser for STEP-formatted data (specifically the ISO 10303-21 standard), but I've run into a roadblock revolving around a single character - '$'.
A quick Google search reveals that in STEP, this character denotes an 'unset' value, I interpreted this as an uninitialized value, however I don't know exactly what I should do with it.
For example, take the following definitions:
#111=AXIS2_PLACEMENT_3D('Circle Axis2P3D',#109,#110,$) ;
#109=CARTESIAN_POINT('Axis2P3D Location',(104.14,0.,0.)) ;
#110=DIRECTION('Axis2P3D Direction',(1.,-0.,0.)) ;
To me I cannot see how this would even work, as the reference direction is uninitialized, and therefore an x-axis cannot be derived, meaning that anything using this Axis2Placement would also have undefined data.
Normally when I reach this point, I would just define some sort of default data for the given data-type (Vertices (0,0,0), Directions(1,0,0), etc.), however this doesn't seem to work, because there's the chance that my default direction would cause conflicts with the supplied data.
I have Googled what to do in this scenario, only to come up with nothing.
I also have a PDF for a very similar STEP format (ISO-10303-42), but it too doesn't mention any sort of default data, or provide any more insight in to how this works.
So, to explicitly state my question: what do I do with uninitialized data in STEP (ISO 10303-21) data?
You need to be able to represent 'unset' as a distinct value. It doesn't mean the same thing as an uninitialized value or a default value. For example you might represent AXIS2_PLACEMENT_3D as an object with data members that are pointers to point to CARTESIAN_POINT and DIRECTION, and the $ means that that pointer will be null in your representation.
Dealing with null values will depend on the context. It may be some kind of error if the data is really necessary. Or it may be that the data isn't necessary, such as if you don't need the axis to be oriented, and a point and direction are sufficient to represent the data.
In this case: #111 is local coordinate system with following 4 attributes:
character name;
pointer to origin (#109);
pointer to axis (#110);
pointer to second axis (reference direction).
If #111 is a coordinate system of circle (I guess it with 'name' value), axis is normal of circle plane, while reference direction points to start of circle (position of zero t parameter of circle). Since a circle is closed curve, you can locate this zero t position in arbitrary place, it has no influence on circle geometric shape, reference direction in this case is not mandatory, and is omitted. And it is your choice how you handle this situation.
When $ sign is used , the value is not required. Specifically, if there are a series of optional values and you want to specify a value for, let's say, 3rd optional argument and you don't want to specify values for the 1st and 2nd optional arguments, you can use $ sign for those two.
Take a look here for a better description.
Does there exist a modified Colemak keyboard layout designed specifically for programming?
I went cold-turkey on the Colemak keyboard layout a few days ago and I really like it for normal typing, but I have some issues for frequent programming characters like the ; (semicolon) key. A modified layout that has direct mappings for braces and parentheses would be nice.
Obviously I could remap these keys myself via trial-and-error, but I'm hoping someone has done some testing to determine an optimal layout for common language characters.
Background
I am obsessed with efficient workflows, and the results from my experiments are very compelling and I guarantee it is very much worth the endeavour. This is also my third major edit, and I have more or less settled upon the layout I use today.
I will be try to be brief and to the point.
Current Layout:
Your fingers rest on the highlight
Wide Angle Mod: Right hand has shifted one column. Benefits:
Less stress on right wrist
Layout is now symmetrical
Shift R + Level5 is easier to reach.
8 layer layout requires 3 modifiers:
Shift
Level3 usually known as Altgr
Level5
include "level3(lalt_switch)" // Left Alt
include "level5(ralt_switch)" // Right Alt
level5 is very obscure and extremely useful to know about, if you wish to expand. For example, on my layout, it would allow for around 200 extra characters to be added.
How 8 Layers works
Layer:
No modifiers
Shift
Level3
Level3 + Shift
Level5
Level5 + Shift
Level5 + Level3
Level5 + Level3 + Shift
Numbers
Accessed solely on Layer3
A programmer who uses numbers often, is a bad programmer. See:
https://en.wikipedia.org/wiki/Magic_number_%28programming%29
This was why it was taken off of Level1 ( No Modifiers )
For convenience, it is arranged in a number pad.
1230, constitute the most common numbers, and hence are found on the home row.
The right hand number pad has close access to -+.,#%$*/\;:=, the most relevant mathematical operators.
I search for keys about 10× less compared to a standard 1234567890 layout. I find this much easier and more intuitive to use.
Alternative Characters ( Requires Modifier )
The least common alternative characters were delegated to Level3 and Level5 modifiers. They were mapped with the following reasoning:
# resembles Q
& resembles B
$ resembles Z
× resembles X
~ resembles W
` is on C, "aCute"
| is on V, "Vertical pipe"
% is on M, "Modulus"
# is on H, "Hash"
< and > Easy Access for writing html etc.
^ is next to < and >
+ and - is next to the Numbers, with - easiest to access
Alternative Characters ( No Modifier required )
Generally the most common programming characters that you will type exist here:
? ! in the corner, because they typically close off sentences. Colemak was designed that letters that end sentences are more common on index and middle fingers, and placing it here on the pinky improves hand movement. ! also remains on its original position.
[ and ] are easy access, because Regular Expressions tend to use them a lot. They mirror ) (.
) ( are reversed because it is easier to roll the fingers from the pinky to the index finger. The following trigram is also very common: (); and works best in this orientation.
" is on an easy access area, and mirrors '.
' is on the opposite hand as s which is important for the 's bigram.
{ } are usually automatically handled by editors, so they are placed in the hardest to reach region.
* and / are for the /* bigram and are common vim commands.
\ is on the right hand at the far corner, to resemble Escape and to work best with the following bigrams, \t \n \r
; : = are all similar, and resemble Return. Again, because they exist near the corners, and they typically end sentences, they work best on the Pinky and Ring Fingers.
Prior Next aka Page Up Page Down are directional keys in the middle. This is exceptionally useful on Thinkpad Keyboards, as they are right next to the Trackpoint. Even without the trackpoint, it is nice when it comes to just scrolling through documents. The reason why they are not the same as Page Up Page Down is to grant more flexibility for run configurations.
_ the underscore here works well for writing object names, and works well with the m_ and s_ bigrams. It also is not a letter because that makes shifting it a painful exercise.
Directional Keys
Inspired by Vim
Without the "Wide Angle Mod", the thumb will cramp up reaching for Level5
Amazing for editting regular documents.
Letters
Shift + [A-Z]
Capslock and Enter Removed and replaced by Shift
Shift's are replaced by Control
Shift's are 3× more comfortable
Control's are 5× more comfortable
Capslock was not missed. Prefer it as Shift over Backspace or Escape provided that I have access to those keys on Level3 or Level5
Return
Placed on the o because in vim, its functionality is similar to Enter.
Sometimes can cause issues with Games which will not detect it.
Surprisingly, not a big issue. I would consider it maybe 1.3× more difficult to use compared to its original position, which is great tradeoff to be able to get Shift on the home row.
Functional Keys
Accessible by either modifier.
Backspace is on the left pinky, to be intuitive with the direction you are deleting.
Delete is on D, and is intuitive with the direction you are deleting.
Escape for some reason, feels best on the Ring Finger, rather than the pinky.
End and Home are inspired by a colemak Vim configuration:
InSert, which will go to the beginning of the line before editting.
Append being on the T, which goes the opposite direction.
Backspace is used 10× more ( Meaning that I will use the Home Row position 10× more, rather than its default position. ).
Delete is used about 20× more.
Escape is used about 15× more.
Home and End is used about 200× more often and utilized far more often, being especially useful in editting documents outside a vim environment.
Todo:
If you are up for the challenge, there are some useful ideas I have played around with, however was not able to formally add to the layout simply due to the difficulty of doing so.
In short, you could theoretically map characters or functions to the modifier keys, that only execute upon a key release. For example,
Press Shift and no other keys
If you release it within 1 second, Its alternative key would execute.
And that's that.
Lazy Installation:
Go here: https://paste.ubuntu.com/p/TbJJkm2vxM/
sudo vim /usr/share/X11/xkb/symbols/us
Replace the contents
WARNING: This will replace your default Colemak.
Configuration Files
.vimrc: https://paste.ubuntu.com/p/JSKMwrPMPY/
~/.config/sc-im/scimrc: https://paste.ubuntu.com/p/Vx64STMtHC/
.config/qutebrowser/config.py: https://paste.ubuntu.com/p/mcymX92tBF/
I realize this question is already a year old, but here is my reply in case it helps anyone else.
This is a problem I have dealt with more often than I care to elaborate.
Suffice it to say that no, even after months of search, I have yet to find a suitable "Colemak for programming".
It has the same annoyance as the usual QWERTY in overusing the right pinky for special symbols and a remap would have been desirable, but now that the mess is done, there won't be any immediate solutions.
There's only two things you can do:
1) Make a custom layout keyboard. There are various tools to do this on Win/Lin/Mac. This is neat as you can just rearrange everything as you see fit. The huge drawback, on the other hand, is that nobody else uses your keyboard layout, and if you ever are asked to type something on a computer, you will be in trouble, as your muscle memory is entirely different.
2) There is a keyboard layout called Programmer Dvorak, which aims to solve your problem. Here, the drawback is that programmer Dvorak is relatively unknown compared to the standard Dvorak keyboard, so same issue as above. It only rearranges special symbols, however, which means you could still use the standard Dvorak if so required (and it is far more widespread than Colemak). Be prepared to spend months in the transition, though.
Alternatively, you could try and opt for a third option and try to persuade the Colemak community in developing a programmer-friendly version of colemak. But this will take time and I wager you will find few supporters.
have you had a look at the dreymar wide angle mods on colemak.com?
you could stick the ; in the middle of the keyboard for easy access with [ and ] above and below it perhaps?
I was wondering whether there was any way of making bash send different codes for key combinations that include the shift key? for instance, (Ctrl+V shows me that) Ctrl+N and Ctrl+Shift+N are interpreted the same (^N). Or is there a terminal that can make the difference? Or can bash me modified so that it does?
A terminal doesn't interact directly with your keyboard; it interacts with a stream of bytes that it receives, which are usually (but not necessarily) generated by your keyboard. For the printable ASCII values, there is an obvious correspondence between the value and a key (or combination) on your keyboard. ASCII 97 is a, ASCII 65 is Shifta, and so on.
However, there are the 32 non-printing control characters from ASCII 0 to ASCII 31, called which because they were intended to control a terminal. In order to enter them, the Control was added to allow you, in combination with the other keys, to generate these codes. A simple scheme was used. Pressing Control-x will generate the control code corresponding to subtracting 64 from x. Since # generates ASCII 64, Control# generates ASCII 0. The same mapping holds true for A through _ (consult your favorite ASCII reference to see the rest of the correspondences).
However, whether or not you need a shift key to generate ASCII 64 through ASCII 95 depends on your keyboard. On my US keyboard layout, only [ and ] can be typed without a shift key. (Remember, it's the uppercase-letter ASCII range we're using here, not the lowercase.) So to simplify, I suspect it was decided that Shift would be ignored in determining which keycode is sent with Control-x. (Note that if for some reason your keyboard had two of the characters between 64 and 95 generated by a key/Shift-key pair, your terminal would need to define an alternate mapping for the associated control character.)
All this is simply(?) to explain why ControlShift-x and Control-x are typically the same. Obviously, your modern operating system can distinguish all kinds of keyboard combinations. But out of the myriad possibilities, only 256 of them can send unique values to a terminal; the rest must necessarily duplicate one or more of the others. To be useful, they need to be configured to send some multiple-byte sequence to the terminal, typically beginning with ASCII 27 (ESC). When terminals receive that byte, they pause for a moment to see if any other bytes are coming after. Keys like function keys, arrow keys, etc. have fairly standard sequences they send, which the terminal interprets in various ways. Other keys (like ControlShiftn in your example) have no agreed-upon meaning, and so your terminal emulator must assign one. Most emulators should allow you to do this, but how they do so is, obviously, program-specific.
There's are two great write-ups on keyboard shortcut customization in bash here:
Bash: call script with customized keyboard shortcuts?
In bash, how do I bind a function key to a command?
iTerm2 allows you to map key combinations like Control+Shift+, (which should represent C-<) to an escape sequence. Emacs translates certain escape sequences to the expected key sequence by default. Therefore, by remapping the desired key combination in iTerm to the appropriate escape sequence, you can get the behavior you want. See this response for specifics.
Suppose you are on line 640 and notice the following on line 671:
if (jumps_over(quick_fox[brown],the_lazy_dog)) the_lazy_dog.bark();
What would be the most key efficient way to navigate to "bark"?
This is a common misconception about Vim: Vim is not designed to be efficient.
Vim is designed to use small building blocks in repeatable, often complex combinations, to achieve your goal. It is not an inherently efficient process, but for a subset of complex tasks, it's useful. For example, [motion][macro], or [count][command], these are small building blocks combined together in chains. Clicking on the screen is the most efficient movement, but might not be useful in a subset of a large text manipulation task where you have to do it thousands of times.
Here are all the ways I normally use that I can remember, you can see none of these are efficient uses of movement nor my cognitive processing power. (IDEs do things efficiently by taking out all the work listed below).
Once on the line I would personally use f.l since a quick scan shows that's a unique character. Or T. if you're past it. If there ends up being more than one . I would use ; to repeat the find until I got to it. Or, mash w or W until I got close, since trying to guess where lowercase w will take you when punctuation is involved is basically impossible in Vim.
If you have :set relativenumber on you can see how many lines away it is, and type nj to go there, then type f. to jump next to it to it
If you have :set number on you can type (since you'd know the line number) 671G (or :671Enter) f.
If you had marked that line with, say ma you could jump to the line with 'a or the exact char with `a (but most keyboards make ` useless to reach :( You probably won't use this one if it's a random look-need-to-fix jump.
If you have EasyMotion installed you could type leaderleaderfbsubchar to jump right to it
You could search for it as #kev suggests and use nN to bounce around until you get it. If bark is common but the_lazy_dog is unique you could do /dog.b/eEnter (e places cursor at end of match) and pray to the Vim gods that your search was specific enough to only match that line. That's more of a fun guessing game.
Depending on where the line is on the screen, you could use (n offset)H, M or L (high middle low) to get closer to it and use jk once there.
Or if the line has empty lines above / below it you could type the super handy { or } to help you jump close.
Or you could use the mouse if you're on a laptop where the trackpad is nearby + in gvim . I'm serious about that, even though I'd probably never do it. if you've played enough first person shooters your trigger finger may be more accurate and fast than any keyboard shortcut ;)
Despite all of Vim'm crazy keyboard power, there is not always a direct nor good way to do something, like very specific jumps. You need to keep and continuously build a bag of tricks to help you move around and use the appropriate ones for the job. I use all of the above fairly evenly and often (I use relativenumber), depending on what I think would be fastest. EasyMotion is pretty handy except that 5 keystrokes to perform one command is really awkward and error prone to type.
So in my humble few years of Vim experience, I'd say there is no good way to do it, but there are a lot of mediocre ways, that you can combine into a decent way.
Press /barkEnter. (maybe n is required)
(It depends on the shape of text. Without the information, I cannot provide a best way.)
If you wanted to increase the likelihood of a hit (ie. reducing the likelihood of having to hit n) using #Kev's suggestion, perhaps change your regular expression to include more text and offset your cursor from there. eg:
/dog\.bark/e-3
Turn on relative line numbers and the 31j becomes a VERY natural motion; this gets you to the line you need to be on.
Then, look for a unique character to the line near where you want to be. In this case . is unique and just before bark. So, f.. Then l and you're good.
So in total: 31jf.l.
(This is not always how it will work. Sometimes it's just as quick to use /bark once you've jumped to the line. Sometimes it's quicker to use /bark initially and just n a number of times to the line. Vim give you the tools, your code will always differ.)
Kev's answer works assuming bark is an uncommon word. You could be hitting n quite a few times.
I'd go with
671G to jump to the line,
$ to jump to the end of the line, and
2b to drop the cursor on the b.
Edit: reading over Andy's answer, I really have to agree with this:
Despite all of VIM's crazy keyboard power, there is not always a direct nor good way to do something, like very specific jumps.
I would opt for navigating around in approximate steps, like 9j to go down 9 lines. When you do this on reflex, you can navigate much faster than it takes to read line numbers or character position. It might end up being more keystrokes, but I prefer the extra speed.
Actually, I don't want to say that I think the most efficient way is use your mouse,
another way use command line:
/.*dog\&.*bark
this will reduce the frequency compared to /bark(and many n maybe)
One way of jumping to char on the same line was not mentioned, yet.
Use
61|
61"pipe", to jump directly to [b]ark in control mode.
I didn't incorporate this into my regular jumping, because the number is usually a guess. with with fixed 80 chars per line you can get used to it and it will be very efficient. But the pipe key is inconvenient imo. I'm planning on using it more often because of its elegance and efficieny.