<wpwrak>
that's simply /prefix/project/repo/dir if you make it flatter, you risk conflicts
FIQ has quit [Read error: Connection reset by peer]
<wpwrak>
we can use environment variables if you want, QIHW_BASE, NEO900_BASE, or such, or EDA_TOOLS
<timclassic>
Evening
<DocScrutinizer05>
env vars sound good
<DocScrutinizer05>
the latter particularly
<DocScrutinizer05>
I guess you're not much excited about my pageflipping achievents in kicad
jefrite has joined #neo900
<wpwrak>
(env vars) hmm no, i was thinking of a use elsewhere. as far as i know, in .pro we can't have variables :(
<DocScrutinizer05>
so could you "bridge" the /prefix/project/ part with a symlink to kicad's parent dir?
<DocScrutinizer05>
or even into kicad dir
<DocScrutinizer05>
I don't mind about arbitrary depth of filehierarchy dowm from project dir, but not upwards please, people might have their project in their "root" dir ($HOME)
<wpwrak>
but it's a relative path, precisely to avoid having to have a fixed place in the hierarchy
ashneo76 has joined #neo900
<wpwrak>
hmm, i have an idea ...
<wpwrak>
please pull and try make sch
<DocScrutinizer05>
make sch will still not work for me
<DocScrutinizer05>
my kicad invocation isn't compatible with your way to invoke it
* DocScrutinizer05
just managed to not say "people might not even have make installed" ;-)
<wpwrak>
well, you can set the symlink manually
<DocScrutinizer05>
sure thing, no problem. that was the idea
<DocScrutinizer05>
I don't think there was a working way to do that automatically anyway
<DocScrutinizer05>
(maybe short of a find / -name anelok-magic-anchor
<DocScrutinizer05>
)
<wpwrak>
i just set a default if nothing else is there. and as a bonus, you get an error if you have a dangling symlink :)
Defiant has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 276 seconds]
Defiant has joined #neo900
<DocScrutinizer05>
meh! CHROOT
<DocScrutinizer05>
this mess here needs some thorough cleanup
<DocScrutinizer05>
I mean: /home/jr/vagrant-test/kicad-devuan-amd64/chrootdir/home/compile/kicad/kicad-libs/components honestly unbearable ;-)
<DocScrutinizer05>
it's getting late here
<DocScrutinizer05>
n8
<wpwrak>
sweet dreams ! :)
<DocScrutinizer05>
interesting question: what happens to a mount when you mv the mountpoint or its parent dir?
<DocScrutinizer05>
trivial answer: nothing
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
pagurus` has quit [Ping timeout: 276 seconds]
pagurus has joined #neo900
chainsawbike has quit [Quit: yep... i broke it good that time...]
chainsawbike has joined #neo900
<wpwrak>
DocScrutinizer05: you'll need to git pull before your next commit
<wpwrak>
err, before your next push
FIQ has joined #neo900
announ has quit [Quit: announ]
xes_ is now known as xes
jonsger has joined #neo900
paulk-aldrin has joined #neo900
jonsger has quit [Ping timeout: 260 seconds]
jonsger has joined #neo900
jonsger has quit [Client Quit]
SylvieLorxu has joined #neo900
Pali has joined #neo900
<DocScrutinizer05>
I always do
<EndZ>
actually it's impossible pushing without pulling first
<bencoh>
without -f, that is
<EndZ>
nobody pushes with -f
<EndZ>
except he wants to fuck people up
<bencoh>
:)
<atk>
EndZ: it's perfectly normal to push with -f to your own personal development branch you pushed to allow someone else to review it.
<atk>
Pushing with -f to a branch which other people rely on is, on the other hand, a bad idea.
<EndZ>
why should I push with -f on my own personal branch?
<bencoh>
let's say you rebased beforehand
<DocScrutinizer05>
[Note!] bq27421-G1 SLUSB85E "9 Applications and Implementation" ff. is pretty much infested with errors. (e.g: external shunt R assumed there. Layout suggestion based on that!) Don't rely on any info in those §§
<wpwrak>
"the sociopath's guide to git. today's chapter, on the frequent use of push -f" ;-)
<hellekin>
push -f? It's only for private repos when you really made a big mistake and you know nobody has a copy. I.e., never use it.
<EndZ>
actually i usually push, see someone else pushed and then pull but, yes
<atk>
EndZ: because you changed something after it was reviewed and don't want to stack commits which fix commits you just made
<DocScrutinizer05>
^^^ is what I use according to most rececent instruction
<atk>
probably better to pull --rebase
<EndZ>
atk: i rather make those commits, instead using this insane command ;)
<atk>
It's not insane
<EndZ>
well
<atk>
pretty trivial
<EndZ>
when i learned git, i was told "do not use it"
<atk>
Happens a lot especially with github style development
<atk>
but useful outside of that
<EndZ>
so i do not use it, if there're cheap alternatives like "more commits"
<EndZ>
srsly, commits are free, why bother.
<atk>
they're not free
<atk>
they describe the project history
<EndZ>
yes.
<EndZ>
and git pull -f destroys it
<atk>
if a feature is in development and you end up creating 15 commits, 14 of which make small modification to the first one, you're making a useless mess
<atk>
I said push
<EndZ>
/s/pull/push/ sry
<EndZ>
well, i don
<EndZ>
't think so
<EndZ>
if I want a not so detailed history, i create a separate one
<atk>
It's pretty mandatory when to allow someone to review something you are forced to push something
<EndZ>
and for that there are the "fix commits"
<atk>
This doesn't happen in mailing list development style because you have the commits local and simply show someone patches
<EndZ>
which document the development process
<atk>
that part of your development is already documented elsewhere
<EndZ>
well, what happens if there is suddenly a bug after review
<atk>
"add feature X" "fix feature X because it wasn't correct" "fix feature X because still wasn't how the person wanted it" "fix feature X because more changes"
<atk>
that's a completely separate issue
<EndZ>
well, i rather got these fixes in the history
<atk>
when you're trying to create a set of patches to add / change something you want them to be centred around that thing
<atk>
Once everyone is happy and that thing is merged, if there's a bug, yes, you create another commit
<EndZ>
but the history was destroyed, which maybe documented how the bug was created
<atk>
but when you and a small group of people are being indecisive about how something should be done, and create 20 commits out of one small change, you don't want to push 20 commits, you want to push one commit
<DocScrutinizer05>
wpwrak: I have sheet 5 fuel gauge in edit
<atk>
EndZ: what?
<EndZ>
maybe i got sth wrong
<atk>
Consider this trivial example
<wpwrak>
DocScrutinizer05: very good. one of our more unexpected disaster zones :)
<DocScrutinizer05>
indeed
<DocScrutinizer05>
sloppy addition
<DocScrutinizer05>
a few bugs in bq27421 circuit
<wpwrak>
DocScrutinizer05: so the choice for the 2nd chip will be BQ27421YZF ? (there's a whole list). if yes, i'll add it to the block diagram as well
<atk>
EndZ: you have a project which is some kind of web browser and you introduce a way to clear the history. You add this feature on a new branch, make a commit, and push the branch to your github fork of a repository (or just your fork, doesn't need to be on github). You then make a "PR" (github term, alternatively, you just tell someone where to find the repo and which branch to take)
<atk>
this person looks at your changes and says: "this works fine but there's some style issues, could you read this section of <some coding standard> and amend it"
<atk>
you go off and do that, you make a second commit "fix styling" right after the previous commit
<atk>
this looks stupid in the history, nobody makes a commit and then fixes it 5 minutes later
<atk>
people just ammend the commit most often
<atk>
but you can't do that because you pushed... well you can
<atk>
you just use -f
<atk>
if someone is relying on your dev branch, on your dev copy of the repo, vs the actual repo and the actual master branch, that someone is either you, someone you're working on this feature with, or an idiot.
<DocScrutinizer05>
wpwrak: (the choice) about to evaluate all that
<EndZ>
atk: dunno, i like not destroying things.
<DocScrutinizer05>
so far 421 looks not bad
<atk>
(oh, and there's a fourth option, that person is the reviewer and the reviewer has not yet merged your branch
<atk>
EndZ: commit --amend "destroys" things in an identical way
<wpwrak>
atk: the problem is that then you have to be very very careful not to have people use your dev branch. what you're describing can be done (and i know people who work this way on a regular basis), but it needs a lot of discipline, and clear communication.
<atk>
wpwrak: No, seriously, if someone is touching your dev branch on your dev repo that person is asking for trouble
<wpwrak>
EndZ: i use commit --amend about as often as commit without --amend :) though never on anything i've pushed, obviously :)
<atk>
wpwrak: they would have to go out of their way to find your alt repo (a lot of the time, a difficult task) then they need to find this dev branch, then they need to clone your repo and pull your branch
<wpwrak>
atk: yes, if they can tell what that branch is. not everyone is clear about what they consider their "private" branch.
<atk>
it's quite impressive by any standard for someone to go so far off the track to do something so stupid
<atk>
but this is in a separately hosted repository
<wpwrak>
atk: and "branch" can mean "repo"
<EndZ>
atk: git log --oneline --first-parent
<EndZ>
problem solved
<atk>
presenting the messy history in an alternative way is not a solution
<EndZ>
it's only messy, if the presentation is messy.
<atk>
This is like me saying "my room doesn't look messy if you just stare at the ceiling"
<bencoh>
I actually dont use push -f either, unless the only purpose of the branch is to publish work-in-progress that needs to be rebased (think kernel) or amended ... pretty close to what atk is describing
<atk>
Exactly!
<bencoh>
so that in the end someone will be able to do just "merge" on the other side
<atk>
And it's just common courtesy that you at least rebase your changes if manual merging is required
louisdk has joined #neo900
<DocScrutinizer05>
re [note]: see >>9.2.2.3 Sense Resistor Selection<< what a BS
<DocScrutinizer05>
>> The standard recommendation based on best compromise between performance and price is a 1% tolerance, 50 ppm drift sense resistor with a 1-W power rating.<<
<DocScrutinizer05>
wpwrak: do we want jointpoints on "POWERED" label connects?
<DocScrutinizer05>
wpwrak: do we have a special DNP 0R component?
<DocScrutinizer05>
should we?
<DocScrutinizer05>
wpwrak: I'm introducing a new component reference scheme: all DNP on sheet N start their references at ?N99 (e.g. R599) and count downwards
<DocScrutinizer05>
only if the component is assumed to never get populated, IOW it's not part of the (even augmented, complete) circuit design
<DocScrutinizer05>
those components are subject to deletion in a later optimization step, if needed
lkcl has joined #neo900
<DocScrutinizer05>
e.g. bypass 0R to keep the design working when e.g. leaving out BQ27421 (between BAT and SRX), or for bypassing FET switches
louisdk has quit [Ping timeout: 258 seconds]
<DocScrutinizer05>
wpwrak: we need some "battery present" sensor on BSI that works independently/non-interferently with e.g. ADCIN resistance probing that applies voltage to BSI - means we can't rely on the (!)NTC in battery to do a proper pulldown all the time
<DocScrutinizer05>
rather we *might* use a window discriminator with a voltage window that's exactly detecting the float voltage of BSI
<DocScrutinizer05>
or a combination of 0V detection when NTC-pulldown and no active HDQ or ADCIN, plus sensitive current detection on R502 100R
<DocScrutinizer05>
we need that for bq27421 and SIMMUX CD, and possibly also for low latency system power hog disabling aka BAT-SWITCHED power down
<DocScrutinizer05>
the latter (bat-switched) is a shot into the blue so far, needs further evaluation
louisdk has joined #neo900
<wpwrak>
(POWERED) in general, i'd draw anything new with a bit of "wire" on it, so you get a junction point. the "wire" also helps if you drag, so it's good practice to have it.
<DocScrutinizer05>
yeah, noticed you can't hve no junction dot
<DocScrutinizer05>
how to change / swap pins on a schematics component?
<wpwrak>
(DNP 0R) there are some on sheet 2. but they're just regular R0402. in general, i think you could just add a field that says "DNP". we can sort out the rest later, when processing the BOM.
<DocScrutinizer05>
add a field?
<wpwrak>
(add field) press E
<DocScrutinizer05>
mhm
<wpwrak>
(sawp) right click > Edit component > Edit with Library Editor; move/edit pins to your liking; Update current component in current library; Save current library to disk
<wpwrak>
when done, make sure you commit all that's changes. git commit .
<wpwrak>
also, if you change the symbol, changes to the drawing and pins will be updated in the schematics, but if you rearrange fields or modify their properties (size, alignment, etc.), you need to explicitly update with E > Reset to Library Defaults (which will also reset component orientation and placement of all fields)
<wpwrak>
if you get lost (easy, since you're doing all this for the first time) and want to start over: git stash :)
<DocScrutinizer05>
git stash sounds nasty, will prolly nuke all edits done so far
<wpwrak>
in general, i'd suggest to avoid having a lot of similar symbols. we already have an excessive number of them, with copies of the same symbol for different footprint sizes. imho, a very very bad idea.
<wpwrak>
yes, nukes all edits since the last commit. but sometimes that's just what you want.
<DocScrutinizer05>
only if i'd push every 5 minutes
<wpwrak>
well, "nukes" ... they're still around. so you can have them back if you change your mind.
<wpwrak>
you can commit without pushing
<wpwrak>
so you can pile up changes in your local repo without anyone else seeing it. this gives you the option of modifying your commits before pushing. but that's advanced use :)
<DocScrutinizer05>
I think git is only useful when you *really* are completely familiar with it
<DocScrutinizer05>
the problem is that even 90% of knowledge only get you into a hell pretty quickly
<wpwrak>
well, you're on your way to becoming familiar with it :) all the things that sound weird and dangerous now will eventually become something you trust
<wpwrak>
that's called learning :) just because you could get run over when crossing a street, you wouldn't choose to never leave your block, would you ? :)
<DocScrutinizer05>
tnhat isn't any good example
<wpwrak>
(redundant symbols) if they only differ in the symbol name, we should probably make them aliases of one "master" symbol. that way, any style changes have to be done only once. at least i think this is how it should work. never used aliases before. i just "diversify" in the parameters / fields
<DocScrutinizer05>
when leaving the house I could decide to only walk along the wall, keeping touch to it, and when I turn around and go opposite direction I will for sure come back to where I started. With git I do a git stash (complete lack of any resemblence of the command name to what it actually does, no *easy* --help or manpage either) since somebody told me that's the way to undo changes, and desaster accomplished
<wpwrak>
man git stash ?
<DocScrutinizer05>
>>git-stash - Stash the changes in a dirty working directory away<< BLARGH!
<wpwrak>
and what is does is that is basically "commits" you changes to a place that's not in the history. so they are still around, in case you 1) change your mind, or - more common - 2) want to look up some bits of what you've done
<DocScrutinizer05>
>> Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.<< not much better
<wpwrak>
there are other ways to undo things, but they're "lossy". git stash is safer in that regard.
<wpwrak>
"dirty" = has uncommitted changes. much like a memory page is "dirty" if it has been changed but not written to secondary storage yet.
<DocScrutinizer05>
why can't they phrase that like "git-stash - save all modified files to a hidden stash for later, then undo all changes done since last pull/commit/whatever(?)"
<DocScrutinizer05>
all git man pages assume you have a working model of what gitr really does. And to acquire such model you prolly need to read and understand all those obscure manpages
<wpwrak>
*shrug* the man pages can be a bit too technical. most of the time, if i need something i don't remember, i just google for an article on stack exchange. much quicker than wading through dozens of options i don't need.
<MonkeyofDoom>
seriously
<MonkeyofDoom>
git's vocab is fucked
louisdk has quit [Ping timeout: 260 seconds]
<DocScrutinizer05>
>>DISCUSSION
<DocScrutinizer05>
A stash is represented as a commit whose tree records the state of the working directory, and its first parent is the commit at HEAD when the stash was created. The tree of the second parent records the state of the index when the stash is made, and it is made a child of the HEAD commit.<< WAAAAAH!
* DocScrutinizer05
ducks and covers, then decides to better RUN
<DocScrutinizer05>
also not helpful:
<DocScrutinizer05>
oops
<DocScrutinizer05>
"SEE ALSO:" which rather should prominently mention which is the UNDO git command for any git command discussed in that particular manpage
<DocScrutinizer05>
s/(UNDO)/\1|INVERSE/
<wpwrak>
if you want to grow serious fanbase, implement a git undo :)
<DocScrutinizer05>
well, thanks for that. I *hate* tools that don't have a means to undo stuff you did
<Wizzup>
DocScrutinizer05: that is ... almost all unix tools?
<wpwrak>
DocScrutinizer05: -> stack exchange. there's almost always a way to undo what you did. it may just be a bit cryptic :)
<DocScrutinizer05>
Wizzup: no? each mv can get undone by an obvious opposite mv, a delete can possibly get undone by a undelete or a restore from backup, etc
<Wizzup>
sed -i 's/./a/g'
<Wizzup>
you can do the same with git, just use rsync for backups of the git dir. eas.
<Wizzup>
easy.
<DocScrutinizer05>
you get what you asked for, and you honestly shouldn't use -i to deliberately avoid any backup feature, then start bitching about the missing way to undo
<Wizzup>
DocScrutinizer05: it's the same with git.
<DocScrutinizer05>
yes, but obviously there's no clear way to GROK HOW to undo stuff in git, unless you completely understoof the whole beast. And the man pages are maximum anti-helpful. My point
<Wizzup>
I learned git in an hour or so and used only the basic commands for about a year during my study
<Wizzup>
only after that year I learned how rebase works
<DocScrutinizer05>
I had to use rebase to recover from some fuckup in git whe I tried my very first edit of adding one space char to a HTML file
<DocScrutinizer05>
thanks to completely marginal instructions how to do the most basic things
<DocScrutinizer05>
then - to 'fix' stuff - you use yet another obscure git command and that makes maters even worse. Hooray
<DocScrutinizer05>
mah, I got a tool I need to learn, and that tool is not git right now
<Wizzup>
well, you can continue to struggle for the coming days/weeks, or just learn the basics of git and be done with it
<Wizzup>
anyway, back to work...
<DocScrutinizer05>
or I can avoid git and nit struggle with it at akll
<Wizzup>
you don't seem to manage to avoid it very well...
<DocScrutinizer05>
*shrug* - I could part this channel. would help a lot
* Wizzup
sighs
<DocScrutinizer05>
[2016-07-24 Sun 16:47:02] <wpwrak> if you get lost (easy, since you're doing all this for the first time) and want to start over: git stash :)
<DocScrutinizer05>
[2016-07-24 Sun 16:48:45] <DocScrutinizer05> git stash sounds nasty, will prolly nuke all edits done so far
<DocScrutinizer05>
seems you're right - I fail to manage to avoid constant suggestions to use complicated git commands that in the end don't even do what would be needed
<DocScrutinizer05>
I'd say if I want to start over in anything kicad, I "open project" and load the last saved version, without saving the current flawed edits prior to that
<MonkeyofDoom>
"detached head" is just a nightmare and should be *hard* to get into
<DocScrutinizer05>
with my very poor git knowledge, I'd possibly recommend to myself to do a COMMIT after each kicad_save-project. But I maybe rather should do a cp -a * `date`/
<MonkeyofDoom>
rather than something that happens all the time to hapless newbies
<MonkeyofDoom>
or if git had a graphical representation of current git state
<MonkeyofDoom>
that would summarize the object graph and where you are in it
<MonkeyofDoom>
git could do a million things to be approachable but it seems clear that usability is not a goal
<DocScrutinizer05>
git dwim
<DocScrutinizer05>
do what I mean
<DocScrutinizer05>
and git --suggest-a-way-out-of-here
<DocScrutinizer05>
I assume the fact that clicking on any "SEE ALSO:" link always gets you to some "man page" that is about a completely different command, this is untentional and also a close reminescense to true git?
<DocScrutinizer05>
still not sufficiently focused on real workflow examples
<DocScrutinizer05>
and even in this simple thing, I'm puzzled about gitr checkout 's purpose and effect
<DocScrutinizer05>
almost seems likre git checkout was git's way to do a cd(1)
* DocScrutinizer05
looks into giggle and wonders if it's anything useful or just a distraction
<wpwrak>
DocScrutinizer05: in general, if you find some instructions for git, i'd be wary of those that try to make you use some additional tool. even if it's useful, it'll be confusing if you read about ten similar but still different ways to accomplish the same task.
<wpwrak>
and i'd recommend to use git diff often. see what you've changed.
<DocScrutinizer05>
err I'd be supposed to know what I've changed, no? :-)
<wpwrak>
you may find surprises :)
<DocScrutinizer05>
anyway giggle for sure is not a threat to find additional ways to do anything, seems you can't basically do anything at all with it
<DocScrutinizer05>
sorry, you lost me completely
<DocScrutinizer05>
you're recommeding I use a tool I don't know what it does, to achieve a result I don't understand the exact meaning of
<wpwrak>
what tool are you talking about ? and i just said the contrary: stick with git, don't add more tools (git wrappers or whatever). at least not until you're more comfortable with git.
<DocScrutinizer05>
I'm talking about git diff, so no I didn't say something opposite to you
<DocScrutinizer05>
to start with, why would I want to "see what I changed"?
<DocScrutinizer05>
and would it really help to see that on a possibly almost binary file data level?
<wpwrak>
most of properly sized changes are likely to be small, not major redesigns of sheets
<wpwrak>
and git diff is still part of git, not a "new tool" :)
<DocScrutinizer05>
who said "new tool"?
<DocScrutinizer05>
I don't understand the meaning of the previous post of yours
<DocScrutinizer05>
I guess I'm lacking a lot of context you're assuming to be established
<DocScrutinizer05>
to be honest, I wonder if I know the topic
<DocScrutinizer05>
aiui you suggest to use git diff to accomplish some task you consider mandatory for the general workflow. I'm however not familiar with that general workflow and thus can't make good sense from the suggested procedure
<wpwrak>
no, i'm just suggesting to use git diff to see what exactly you're committing. to get a feeling for what's happening.
<DocScrutinizer05>
err
<wpwrak>
but you don't have to. hey, free will ;-)
<DocScrutinizer05>
ok, seems this leads nowhere
<DocScrutinizer05>
I don't even know *when* and *what* I'm committing
<DocScrutinizer05>
[2016-07-24 Sun 15:12:40] <DocScrutinizer05> ^^^ is what I use according to most rececent instruction
<wpwrak>
git add <file> tells git to use this file from now on. it remembers this, so you don't need to tell it again.
<DocScrutinizer05>
can't relate that to the anticipated results from git diff
<wpwrak>
git commit will only commit the file(s) you've added. if you use git commit . or git commit <files> then it will commit all/these files (if they have changes)
<wpwrak>
so if you edit more than one file, please use git commit .
<DocScrutinizer05>
ok
<wpwrak>
also, git diff will tell you if you have uncommitted changes. e.g., if you've missed a file in the last commit.
<DocScrutinizer05>
aah ok, now that makes sense
<DocScrutinizer05>
:-)
<wpwrak>
see, it's easy ;-)
<DocScrutinizer05>
how would I tell hit diff to *list* the changed files, rather than already show the diffs in them?
<DocScrutinizer05>
also the help might be useful, regarding the keybindings to certain commands
<DocScrutinizer05>
I wish it was more context specific
<DocScrutinizer05>
at least it doesn't introduce "new ways to accomplish a task" since it lists the plain genuine git commands
<DocScrutinizer05>
Oh My Gosh! "Tools"-"Annotate" "use sheet number *100" results in R601 on sheet_5
<DocScrutinizer05>
again thanks to that nonsensical index sheet needed for kicad
<wpwrak>
that's when "exit without saving" or "git stash" come in handy ;-)
<DocScrutinizer05>
please!
<wpwrak>
if we many _any_ changes to the sheets, the automatic numbering fails anyway. we'll just have to do it manually.
<wpwrak>
(any changes) e.g., merge or split sheets, reorder, and so on
<DocScrutinizer05>
sed -i 's/\([RCUX...]\)5\([[:num:]][[:num:]]\)/\16\2/g' sheet*_5.*
<DocScrutinizer05>
the automatic numbering seems not that bad after all
<DocScrutinizer05>
don't see why we need to do it manually
<wpwrak>
it's just extremely fragile. and manual numbering isn't *that* much of an effort either. after all, you typically do it once per component, and that's it. unless you get ambitious and want particularly "nice" numbering.
<DocScrutinizer05>
I hoped for kicad to help find a free reasonable number for new component, but this way this will fail
<DocScrutinizer05>
alternative with manual annotation: find the free number manually
<wpwrak>
yes, you can reset the numbers. but that invalidates all references you may have created in the past. e.g., if you've mentioned a component somewhere.
<wpwrak>
also, reset won't be so much fun once the layout starts.
<Defiant>
yeah, it doesn't know groups either (e.h. power starts at 600)
<DocScrutinizer05>
this could get avoided by "keep existing numbering"
<wpwrak>
"keep existing numbering" has the issue that changes in the sheet sequence lead to mixed numbering
<DocScrutinizer05>
don't get me wrong, I much rather prefer teaching kicad to not need that crappy idiotic index sheet, or at least not as first but as last sheet
<wpwrak>
good luck with that ;-)
<DocScrutinizer05>
yes, or rather: changes in the sheet sequence has the issue that it leads to mixed numbering
<wpwrak>
as far as i understand the sheet sequence, it comes from traversing the sheet hierarchy. no manual overrides.
<DocScrutinizer05>
(good luck with that) either that or we do a global renumbering along the line of sed command sketched above
<wpwrak>
but maybe there's some feature i don't know about
<wpwrak>
be careful with sed. it's easy to change something unrelated
<DocScrutinizer05>
I know#
<DocScrutinizer05>
thus pretty please let's try to fix this index sheet issue
<wpwrak>
btw, when you run ERC, it will complain if there are unnumbered components, and tell you which one is "next". so you can use this to guide you through manual numbering
<DocScrutinizer05>
I wouldn't even mind to change _real_ sheet_1 to A2 and make it parent sheet that has the index shit and *also* has the _real_ sheet_1 schematics
<wpwrak>
the index sheet is the top of the tree. as far as i know, that makes it #1, unless you change sheet number generation code in kicad
<DocScrutinizer05>
see what I just said
<wpwrak>
(a2) your solutions always seem to be much worse than the problem you're trying to solve ;-)
<DocScrutinizer05>
we can set frame individually per sheet
<DocScrutinizer05>
and aiui you can place components (friggin sheet symbols) even outside of the frame (yet to test that)
<DocScrutinizer05>
oooh how I love my ctrl+shifz+PgUp :-D
<DocScrutinizer05>
and it would put some features of kicad to a purpose
<DocScrutinizer05>
if you *really* want a dedicated page filled only with scale 1:8 sheet symbols, we can move to that style at end of schematics editing
<DocScrutinizer05>
btw the approach I suggested also en passant 'fixes' the page number issue as found in pdf
<DocScrutinizer05>
and indeed the main issue is kicad lack of versatility in auto-annotation not allowing user defined patterns to use instead of "sheetnumber*100"
<DocScrutinizer05>
for me ERC not only doesn't suggest a number, it not even gives any hint there to find the component that needs annotation - no sheet reference, no graphical hint, nothing
<DocScrutinizer05>
I guess I'm missing something elementary
<DocScrutinizer05>
I guess I *must* be missing something, since there's a pointless button "Delete Markers"
announ has quit [Quit: announ]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined #neo900
sn0wmonster has quit [Ping timeout: 260 seconds]
Guest91116 has joined #neo900
Guest91116 has quit [Ping timeout: 276 seconds]
sn0wmonster has joined #neo900
AndrewX192 has quit [Ping timeout: 265 seconds]
sn0wmonster has quit [Ping timeout: 260 seconds]
sn0wmonster has joined #neo900
<DocScrutinizer05>
anyway moving sheet1 schematics to master sheet, then deleting '$Sheet\n.*\n.*\n.*\nF1 "neo900_SS_1.sch" 60\n$EndSheet' from neo900.sch seems to work for as far as sheetnumbers are concerned. Also seems neo900.sch sequence of $sheet-includes defines the sort order and thus sheet number
<DocScrutinizer05>
I found no way to redefine/edit the general design of hierarchical sheet symbols. Resizing the rectangle and the text size is seemingly all that can get done about it (except of stuff like "import pins")
<DocScrutinizer05>
so setting size of the sheet text to ~0, and adding plain "Text" into the resized sheetboxes as seen in http://wstaw.org/m/2016/07/24/plasma-desktopoy2277.png, is probably as good as it gets. Which is not THAT bad after all
<DocScrutinizer05>
how would you use git for temporary files that eventually should get deleted? I gather the answer is "not at all"? ;-)
timclassic has quit [Remote host closed the connection]
sn0wmonster has joined #neo900
zrafa has joined #neo900
Pali has quit [Ping timeout: 258 seconds]
<hellekin>
DocScrutinizer05: branch out and save them there, you can even keep the branch local and never push it to the remote repository.
<hellekin>
with git, branching is very cheap.
<DocScrutinizer05>
the question was about publishing
<DocScrutinizer05>
and I wondered how you get rid of a file in git when you want to delete it
<hellekin>
git rm
<DocScrutinizer05>
aah thanks
<hellekin>
it will still be available at earlier revisions though
<DocScrutinizer05>
so let me try a... (moment please...) git add ./tmp/ ./tmp/neo900.sch
<DocScrutinizer05>
would that work?
<hellekin>
I guess you could repack the repo and "forget" about older revisions, but then not pushing is best if you really mean "temporary"
<hellekin>
you could just: git add ./tmp/neo900.sch
<DocScrutinizer05>
:-)
<hellekin>
since the file is in the tmp directory, don't need to add ./tmp
<DocScrutinizer05>
then git commit ./tmp/neo900.sch; and git push ?
<hellekin>
you could also use .gitignore and have your tmp/ directory never committed
<hellekin>
and only available locally
<hellekin>
e.g., echo "/tmp" > .gitignore
<DocScrutinizer05>
nah, the purpose is to publish
<hellekin>
ack
<DocScrutinizer05>
or would the parameter *waht* to publish belong to git push?
<hellekin>
push publishes to a remote repo (not necessarily a public one though)
<DocScrutinizer05>
yes, I know that
<hellekin>
I didn't get your question I guess
<hellekin>
you can publish branches
<DocScrutinizer05>
now let's say I got 3 changed file x, y, z in my local git workdir, but I only want to publish y
<DocScrutinizer05>
I gather git just isn't made for this
<hellekin>
if x and y are already in the repo, git will detect them as modified and propose them for staging.
<hellekin>
so you need to git add y; git commit -m "Added y"; git push
<DocScrutinizer05>
ok
<DocScrutinizer05>
:-)
<hellekin>
but it doesn't make sense to not commit x and z if they're already under version control
<DocScrutinizer05>
that's what a git user says
<hellekin>
better use a branch, commit everything (one file per commit) and then cherry-pick the commit matching the y file into the branch you will push
<DocScrutinizer05>
I got garbage in y and z and definiteloy do not want neither need to publish them
<hellekin>
let's say you're on master:
<DocScrutinizer05>
nah, i'm out
<DocScrutinizer05>
when I hear "master", I mumble "yes, massa" and head out
<hellekin>
"400: No WebRTC Support. Please use Chrome or Firefox." No thanks.
<hellekin>
I like cat better :)
<pigeons>
:)
<DocScrutinizer05>
I however don't see how cooperation between co-authors in one project shall work when git is not capable of simple things like sharing a temüporary draft file
<hellekin>
DocScrutinizer05: it's very capable. Just use branches. The fact you have a block doesn't make git less capable.
<hellekin>
but really, I'd rather set /ignore on anything from you mentioning git because it doesn't go anywhere.
<DocScrutinizer05>
when the overhead to use git exceeds the work done on the file, i think that qualifies git as "not capable"
* hellekin
is happy DocScrutinizer05 doesn't mention systemd as much as git :P
<hellekin>
nothing prevents you from scripting an inotify git commit so you don't have to do it yourself manually.
<DocScrutinizer05>
well, maybe I should set .*git.* on ignore, and simply state that Neo900 can do without it
<hellekin>
that's the approach of etckeeper (except it uses dpkg pre and post-hooks)
<DocScrutinizer05>
I'm not interested in what approach that is#
<hellekin>
how about cvs?
<hellekin>
much simpler interface, so very slow.
<DocScrutinizer05>
wpwrak pesters me since years to use git, and it turns out it's a useless effort each simgle time I try
<DocScrutinizer05>
but honestly when I ask "how do I pusblish kust ONE small temprary file?" and the answer is "that doesn't make sense", then... :-S
<hellekin>
DocScrutinizer05: nothing we can say will convince you. Your view of git is like fractured bone: it grows stronger with every new break.
<DocScrutinizer05>
aha
<hellekin>
you publish one small temporary file just like any other file, because by essence, all files in git are temporary :)
<DocScrutinizer05>
you're doing a really great job in convincing me to rethink
<hellekin>
I lack non-verbal cues to interpret your sentence ;o)
<hellekin>
do you like REPL?
<hellekin>
the git "REPL" is pull; add; commit; push :)
<hellekin>
everything else is extra
<DocScrutinizer05>
first git got introduced in out srv/www/ stuff and I clearly said that this means that those insisting in that change are responsible to do the edits then since I can't. Result: nobody does any edits now. Now we see same thing happening to core project data
<hellekin>
if you're the only one allergic to git, you probably want to come up with another solution that satisfies you, and then see how others can adapt to that.
<hellekin>
whenever I have to work on a project where I can't use git, I still use git locally, and "push" using whatever is needed for that specific context. But at least I know my work is safe.
<zrafa>
hellekin: hi, no more latest news at neo900.org?
<zrafa>
I do not use much irc these days, so
<zrafa>
i visit the web page from time to time
<zrafa>
to know news :)
<hellekin>
zrafa: I wish I could follow what's going on on this channel and summarize it, but I guess automated semantic analysis would understand better than I do.
<zrafa>
I see :(
<hellekin>
zrafa: last highlight I got from wpwrak was about switching to Kicad (I think from Eagle, but I never fired any of these programs)
<hellekin>
zrafa: if that make any sense to you :)
<DocScrutinizer05>
as if this channel was inuktitut and no other stuff ever happens
<zrafa>
hellekin: what do you think could be the best way to have news about the project?
<hellekin>
inuktitut?
<zrafa>
hellekin: I know that wpwrak will prefer kicad over eagle or altium etc :)
<zrafa>
hellekin: I do not know anything about those programs either. Just the names :)
<zrafa>
hellekin: is wpwrak doing schematics and board designs of neo900 using kicad then?
<hellekin>
zrafa: I wish wpwrak would publish for neo900 like he does for Anelok. These regular emails are (were in my case lately) very informative, even for profanes.
<zrafa>
ahh.. and where is anelok news???!!!!! I HAVE GOT NOTHING FOR YEARS! (I was reading qi community mailing list for anelok project)
<zrafa>
news
<hellekin>
zrafa: DocScrutinizer05 and wpwrak have been mentioning that a lot lately. If .sch is an extension for Kicad files, then, err, yes.
<zrafa>
hellekin: btw, are you living in BA? I do not know if I met you some time at wpwrak place. I just know the werner nick :)
<DocScrutinizer05>
zrafa: project switched to kicad sincew eagle isn't a sustainable toolchain for the project anymore, since Nikolaus bailed out for layout
<hellekin>
zrafa: last one I received was first of june about the case update, and yes, on Qi HW list
<DocScrutinizer05>
zrafa: we're inmidst of porting all project data to kicad
<hellekin>
zrafa: we organized quite a number of hacksado at his place :)
<DocScrutinizer05>
which works way better than anticipated
<zrafa>
DocScrutinizer05: wow, those are great news. Only problem the huge and hard work you have on front I think
<zrafa>
DocScrutinizer05: hellekin : I remember the work of wpwrak on gta02-core for a lot of months. Very hard it was I think, and a lot of components were dissapearing from market
<zrafa>
hellekin: asados: then maybe I met you once. Werner must remember surely
<DocScrutinizer05>
that's a completely different story about those components and their sourcing
<hellekin>
zrafa: did you come to BA with robots once?
<DocScrutinizer05>
we should be relatively on the safe side meanwhile, with all of the key components
<DocScrutinizer05>
what's a problem are human resources disappearing
<zrafa>
DocScrutinizer05: :( who are the human resources who are disapeearing?
sn0wmonster has quit [Ping timeout: 265 seconds]
<zrafa>
DocScrutinizer05: at least I hope that you and wpwrak will continue
<DocScrutinizer05>
and it seems in a project like this you could easily waste months and years into educating new team members only to find them bailing out after they got 50% up to pace, and you start all over again
ashneo76 has quit [Ping timeout: 260 seconds]
<DocScrutinizer05>
just for fun I might eventually cound the number of user accounts on our servers
<DocScrutinizer05>
count
<hellekin>
only 9
<hellekin>
DocScrutinizer05: only 4 active users though