* sn0wmonster
just a friendly reminder to everyone to get up and walk around a bit. sitting for long periods will kill your knees, shorten your leg/waist connecting muscles, screw with your back, and make you die quicker.
<Oksana>
sn0wmonster: Thank you :-)
luke-jr has quit [Ping timeout: 240 seconds]
luke-jr has joined #neo900
xman has quit [Quit: Leaving.]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
pagurus` has joined #neo900
pagurus has quit [Ping timeout: 276 seconds]
paulk-collins has joined #neo900
paulk-collins has quit [Remote host closed the connection]
<enyc>
wpwrak: I can't say i read silego in wihetpaper anywhere, or knew exactly the best way to 'follow' engineering, / papers / etc....
<enyc>
wpwrak: theres a neo900.org 'resources' page listing some of them
ahycka has quit [Read error: Connection reset by peer]
ahycka has joined #neo900
illwieckz has quit [Ping timeout: 248 seconds]
illwieckz has joined #neo900
illwieckz has joined #neo900
illwieckz has quit [Changing host]
illwieckz has quit [Excess Flood]
JoHnY_ is now known as JoHnY
illwieckz has joined #neo900
illwieckz has joined #neo900
illwieckz has quit [Changing host]
illwieckz has quit [Ping timeout: 240 seconds]
illwieckz has joined #neo900
illwieckz has joined #neo900
illwieckz has quit [Changing host]
goiken has quit [Ping timeout: 265 seconds]
goiken has joined #neo900
vahe has joined #neo900
Pali has joined #neo900
xman has joined #neo900
goiken has quit [Ping timeout: 265 seconds]
goiken has joined #neo900
<DocScrutinizer05>
how do I completely reset a git to a new clean version?
<DocScrutinizer05>
git clone; again, over the old one?
<bencoh>
if you wanna git clone, then you'd need to remove the directory first
<DocScrutinizer05>
or do I need to delete the dir first?
<DocScrutinizer05>
ok
<bencoh>
I'd probably do something like git clean -xfd && git reset --hard HEAD, but ...
<bencoh>
it depends on what you've done and what you're looking for
<bencoh>
or origin/master instead of HEAD, or ...
<DocScrutinizer05>
the point is I have no clue what I've done so far
<DocScrutinizer05>
seems there's a lot of dirt created from oopses and experimenting and whatnot, that I want to get completely rid of
<DocScrutinizer05>
not understanding git while nevertheless being forced to use it doesn't help to avoid such effects
<MonkeyofDoom>
I think clean -dfx blows away all files, untracked or not
<MonkeyofDoom>
(and puts you back on the checked-out version)
<DocScrutinizer05>
concurrent edits in kicad don't work, no matter if git or not
<sixwheeledbeast>
I struggle with git, I got to understand it a little but i think using it all the time it would come easy
<DocScrutinizer05>
sort of chicken/egg problem, when you neither like chicken in any form fied cooked or whatever, nor eggs
<DocScrutinizer05>
in my case I don't like learning git sufficiently to use it for everything, and I don't want to use it for everything every day either
<DocScrutinizer05>
I honestly think the age old unix toolbox is completely sufficient for my needs
<DocScrutinizer05>
neither mc nor konqueror knows how to handle a git "virtual filesystem"
<DocScrutinizer05>
so the situation is: for unix toolbox I know the commandline commands _and_ I can use a plethora of tools like konqueror, mc, whatever. For git there's zilch such tools and I do not know the commandline commands
<MonkeyofDoom>
git just has a really fucking poorly designed UI
<DocScrutinizer05>
indeed
<MonkeyofDoom>
the commands are not orthogonal, though they could easily be
<DocScrutinizer05>
yep
<MonkeyofDoom>
I've heard people recommend hg but haven't tried it
<MonkeyofDoom>
it couldn't be worse from a UI standpoint
<DocScrutinizer05>
mercurial gets hyped by a few people, but I don't know if it's really better. Anyway it lacks acceptance in the git fan community
<Kero>
find another UI on top of git. There are a gazillion. But understand git, first. As long as you treat git as any other vcs it is not gonna make you happy.
<MonkeyofDoom>
the git protocol and repo layout is the de-facto standard, but it may be possible to ^
<DocScrutinizer05>
so it's quite off the point to consider if it's better, when I have to deal with git anyway
<MonkeyofDoom>
with any luck there's an Hg frontend to git
<DocScrutinizer05>
tbh I tried for 2 months now and I still think a plain rsync would hev kept me more happy than git, for kicad
<DocScrutinizer05>
have*
<DocScrutinizer05>
the *only* benefit of git I can actually see and maybe use is the commit comments
goiken has quit [Ping timeout: 240 seconds]
goiken has joined #neo900
<DocScrutinizer05>
grr, of curse this reset nuked my symlinks e.g. for eeshow
<DocScrutinizer05>
seems there's still some way left to go, to get to a neo900 environment that's not specific but integrates into the existing system
* DocScrutinizer05
gives eeshow `make install` a try
<DocScrutinizer05>
I really don't like git cloning alien libs to make eeschema happy with editing neo900 project
<DocScrutinizer05>
wpwrak: ^^^
<bencoh>
DocScrutinizer05: git is a vcs, rsync is, well ... a sync tool
<DocScrutinizer05>
please either copy those libs into the project verbatim, or find some nifty git hack to have a remote git repo automatically imported
<bencoh>
pretty sure you know and appreciate the difference
<bencoh>
;)
<DocScrutinizer05>
bencoh: I know
<bencoh>
we definitely want to keep track of changes/history and be able to go back to previous states
<DocScrutinizer05>
aha
<DocScrutinizer05>
I don't want to go back to previous states
<DocScrutinizer05>
except those I archived
<wpwrak>
DocScrutinizer05: there is (of course) a nifty git way to do this (submodules). but they're hated even by many very experienced git users. i'm not sure that's really what you want to deal with.
<DocScrutinizer05>
then copy the libs into the project please. It's the method I favor anyway, since I do *not* want to track changes introduiced in a
<DocScrutinizer05>
alien project into those libs#
<DocScrutinizer05>
it's not like neo900 wants to stay up to date with qi-hw latest hype how to draw power symbols
<DocScrutinizer05>
as a general rule, the project should be (and stay) self comprising, possibly even up to the tools used (in a sense that we keep/provide a copy of e.g. the kicad sourcecode of the kicad version we use)
<wpwrak>
DocScrutinizer05: i think we should make a distribution then. maybe some "targetted" devuan ? like there are some specialized ubuntu and red hat for certain areas of interest (electronics, security, etc.)
<wpwrak>
DocScrutinizer05: then you have a clean way to resolve all the dependencies
<DocScrutinizer05>
that's a tad far fetched - nevertheless there already exists such distro: my Vagrant VM
<DocScrutinizer05>
which by the waqy doesn'T use systemd, unlike ubuntu and RH
<DocScrutinizer05>
[2016-09-15 Thu 21:36:59] <kakimir> why does kicad load wrong version of component
<DocScrutinizer05>
[2016-09-15 Thu 21:37:06] <kakimir> preview is ok
<DocScrutinizer05>
[2016-09-15 Thu 21:37:31] <kakimir> and when it placed it's the unmodified version of the component in another library
<DocScrutinizer05>
[2016-09-15 Thu 21:38:18] <c4758p> it uses the first component it finds by that name, traversing the library list in order. reorder your libs in the library preferences
<DocScrutinizer05>
[2016-09-15 Thu 21:38:31] <c4758p> (yes, we know it's broken. yes, it's going to be fixed. ;)
<DocScrutinizer05>
we should try to keep the number of libs used as low as possible, and have them all completely under our exclusive control
<DocScrutinizer05>
[2016-09-15 Thu 22:04:20] <kakimir> c4757p: that is a major bug I say
<DocScrutinizer05>
[2016-09-15 Thu 22:04:35] <kakimir> you may accidentally use wrong component and not even know it
<DocScrutinizer05>
[2016-09-15 Thu 22:04:53] <c4757p> that's why I said it's known, and going to be fixed
<DocScrutinizer05>
[2016-09-15 Thu 22:05:40] <c4757p> it is a major bug that is surprisingly difficult to fix. the fix is planned, and involves a full reimplementation of the library system to mirror the one in pcbnew
<MonkeyofDoom>
that's rough
<DocScrutinizer05>
well, not really something completely unexpected. You always need to manage a project in a way so you take preventative care of such glitches
<DocScrutinizer05>
absolute 100% reproducibility is mandatory for any project of that size
<DocScrutinizer05>
thus we don't want to depend on external libs we have no control over
<DocScrutinizer05>
we define a "gold standard" version of tools we use, and when somebody uses newer version, then it's their responsibility to keep track of incompatibilities and/or glitches introduced - not hard for a huge project like kicad where a glitch gets noticed pretty quickly. But for component libs from random alien projects the situation is more involved
<DocScrutinizer05>
and obviously the lower the lib count the lower the risk something bad happens with those libs anyway
<DocScrutinizer05>
ideally we have one Neo900 specific lib into which we import what's needed and we have full control over that
<DocScrutinizer05>
not even the above mentioned bug would hurt us then
<DocScrutinizer05>
obviously with only one lib there won't be any wrong component version in another lib that kicad could use instead of the one we selected
ravelo has quit [Read error: Connection reset by peer]
ravelo has joined #neo900
goiken has quit [Ping timeout: 265 seconds]
goiken has joined #neo900
ravelo has quit [Quit: liteIRC for Android]
<DocScrutinizer05>
as a general rule of thumb: evaluate, minimize, and then define the dependencies (in our case e.g. "kicad debian linux version 4.0.2, commit XY23Z45ABC". Then ideally make sure you got a backup of those dependencies on your server. Then keep the rest of the project completely free of persistent external dependencies like libs in other repos etc, rather import *everything* into your own project so in the end everything you (or anybody
<DocScrutinizer05>
else) would need to 100% reproduce the whole thing is available on your server. --- since such definition never works without defining the borders of the "world" aka "namespace" aka environment: for us the borders resp prerequisites are a working linux system with a working kicad that is compatible to our gold standard. We assume those prerequisites as not within scope of the project, users may establish/meet them by any way they like,
<DocScrutinizer05>
we might provide the kicad sourcecode of the version of that tool that we defined as gold standard, though that's not absolutely mandatory
Pali has quit [Remote host closed the connection]
_whitelogger has joined #neo900
tjg1 has joined #neo900
edwin has joined #neo900
paulk-collins has quit [Quit: Leaving]
<wpwrak>
DocScrutinizer05: (context) o
<wpwrak>
grr
<wpwrak>
i'm not sure what specific scenario they're discussing. we do control the search order. all the "external" libraries are for specific footprints, the only one with a large number of assorted footprints is neo900.lib
<wpwrak>
the two concerns you raised previously were integration (i.e., you want to be able to have "everything" with a single command), and long-tern availability, i.e., backups
<wpwrak>
the first one is tricky :) the second one can be solved in a number of ways. we already have at least duplication but we can of course increase the redundancy
<wpwrak>
for the first one, there are a number of approaches, addressing the issue for several types of scenarios and workflows
<wpwrak>
the one we currently have is one that involves very little git. since you seek tighter integration, a relatively generic approach are submodules. however, their use is controversial,
<wpwrak>
they can be somewhat tricky to use, and they don't meet the single command requirement (unless we cheat and include semicolons ;-)
<wpwrak>
then there are subtree merges and the git subtree add-on. they have more impact on the workflow, and i'm not familiar with them (just found out about them today). so they would require more evaluation.
<wpwrak>
if you're looking for something quick and easy, we could just generate tarballs. i'm not sure if there is a command that combines wget/curl and tar, maybe a shell script would be acceptable, at least as a temporary measure ?
<DocScrutinizer05>
I suggest simply adding to neo900.lib all the 'external' stuff we use
<wpwrak>
the tarballs would also duplicate the content, so they would serve as backups. we could decide whether to include history or not in them.
<DocScrutinizer05>
I don't exactly understand where the need for such external stuff came from, to start with. I thought we imported all we need, from eagle
<DocScrutinizer05>
my concerns were not exactly "integration (i.e., you want to be able to have "everything" with a single command), and long-tern availability, i.e., backups" but mainly to host everything on our own server and to minimize external dependencies
<DocScrutinizer05>
once we eliminated the external dependencies, there's no obvious reason why it would need more than one `git clone` to create a complete local Neo900 kicad project
<wpwrak>
we have several types of things that are not in neo900.lib: a) things that are completely new (e.g., nik never made them), b) things that had the wrong symbol (e.g., nik's version was not up to date with respect to the white papers), c) things unique to kicad
<wpwrak>
any smaller changes, i made to neo900.lib directly
<wpwrak>
any "new" components that originated from the neo900 project are not in neo900.lib but in ee/hw/components/ the "one big library" approach has issues, especially with projects what have more than one person making changes. also, kicad is moving away from this. pcbnew already has one file per footprint, and eeschema is likely to follow this
<DocScrutinizer05>
I don't mind if that's one big file or a whole subdir tree, as long as it's hosted on our server
<wpwrak>
we could simply mirror the qi-hw kicad-libs repo on neo900
<DocScrutinizer05>
yes
demure has quit [Quit: Either it broke, or I'm fixing it...]
<DocScrutinizer05>
and please keep it in same path/git like the neo900.proj and friends
<DocScrutinizer05>
or make a common parent dir for both, so once command can download the whole structure