| 00:21.01 | *** join/#qi-hardware limpkin (sid20909@gateway/web/irccloud.com/x-pftkkojpfbivhlwc) |
| 02:20.58 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 03:53.23 | *** join/#qi-hardware archang (~archang@122.133.52.113.static.ximdns.com) |
| 04:00.08 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:42.52 | *** join/#qi-hardware luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 05:15.12 | *** join/#qi-hardware incomprehensibly (sid3405@gateway/web/irccloud.com/x-rlxooruqyvzhcrvm) |
| 05:16.06 | *** join/#qi-hardware apelete_ (~apelete@rec31-1-78-194-210-47.fbxo.proxad.net) |
| 07:03.08 | *** join/#qi-hardware dandon (~dandon@185.16.53.188) |
| 07:12.58 | *** join/#qi-hardware dandon (~dandon@185.16.53.188) |
| 07:38.03 | *** join/#qi-hardware doomlord (~textual@host86-152-129-204.range86-152.btcentralplus.com) |
| 08:13.15 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 08:36.25 | *** join/#qi-hardware dandon (~dandon@185.16.53.188) |
| 09:24.51 | whitequark | wpwrak: btw, any luck using solvespace yet? |
| 09:25.07 | whitequark | as an aside, I discovered recently that, only on the gtk port, the tab keybinding was broken |
| 09:25.12 | whitequark | (it shows and hides the text window) |
| 12:00.03 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |
| 12:27.15 | wpwrak | oh, having a "hotkey" sounds nice |
| 12:29.03 | wpwrak | and i haven't tried anything "real" yet. for something major i'd really need variables / stored expressions and possibly tables (computed repetitions) |
| 12:29.48 | wpwrak | i also found difficulties in the workflow. e.g., often enough, it seems to turn everything into a ball of messed-up things that i can only get out with "undo" or by restarting from scratch |
| 12:31.32 | wpwrak | that happens mainly if i start with something that in the end doesn't need to be at the center of the construction. might actually help if one could just freeze recomputing, perform a set of changes, then try to recompute, and hurriedly get back again if recomputing results in the "ball" |
| 12:43.36 | whitequark | (variables/stored expressions) ack. that's on the roadmap "soon", meaning right after unit tests |
| 12:43.44 | whitequark | adding unit tests is... involved |
| 12:44.12 | whitequark | an example of why it's involved is that currently the rendering is done by calling opengl all over the place, and sometimes even invoking the GUI message loop in a middle of computation |
| 12:44.44 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 12:44.54 | whitequark | this already fails with offscreen rendering (that is needed to overlay the editor on Linux and OS X), since... well... if the message loop is not running because it's preempted by a long computation, there's nothing to flip the buffers to show the "long computation" progress bar |
| 12:45.05 | whitequark | but this makes e.g. rendering to a cairo surface impossible |
| 12:45.28 | whitequark | and rendering to gl for unit tests means it's impossible to have reference rendering in the repo, because opengl has major differences in rendering on ifferent platforms |
| 12:45.33 | whitequark | this is very aggravating. |
| 12:45.56 | whitequark | actually, s/unit tests/integration tests/, but the rest is unchanged. |
| 12:46.24 | whitequark | wpwrak: (ball of messed-up things) can you clarify? |
| 12:46.55 | whitequark | you can check the "relax constraints and dimensions" checkbox in the group properties |
| 12:47.08 | whitequark | that lets you to move things around freely without invoking the solver. |
| 12:48.48 | whitequark | (undo) the undo stack is 10 levels deep, which to me seems very silly. |
| 12:49.04 | whitequark | it's mainly that short because of memory management, or lack thereof. it's just a static array. |
| 12:49.49 | whitequark | i feel like a more proper "history" view ought to exist, like in photoshop (that allows you to go back and forth, and even says what action caused the undo state to be pushed) |
| 12:54.31 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |
| 12:54.32 | wpwrak | (gui unit test) sounds nasty. but you could perhaps test the underlying geometry, if that's something you're not testing yet |
| 12:55.21 | wpwrak | (shallow undo) yes, agreed. being able to change history is a nice feature :) |
| 12:56.20 | wpwrak | (ball of things) one mistake i made when trying the "wedge" shape of anelok was that i just accepted default dimensions and tried at the end to set the right, much smaller values |
| 12:56.57 | whitequark | oh yeah |
| 12:57.03 | wpwrak | what happened then is that the while thing reconfigured itself to a completely new topology, and wouldn't flip back to the original topology. |
| 12:57.07 | whitequark | ohhhhh |
| 12:57.12 | whitequark | yeah this is a well known problem |
| 12:57.23 | whitequark | the underlying cause is that many constraints are not signed |
| 12:57.26 | wpwrak | yup. those implicit constrainrs |
| 12:57.28 | whitequark | and so they have bistable configurations |
| 12:57.43 | whitequark | you can explicitly flip them in some cases by entering a negative value for a dimension |
| 12:57.47 | wpwrak | just what i thought :) |
| 12:57.50 | whitequark | or, you can "relax all constraints and dimensions" |
| 12:57.51 | wpwrak | hmm :) |
| 12:58.09 | whitequark | but really none of that is a real solution because this would break hilariously with parametric sketches |
| 12:58.15 | whitequark | the real solution is to make them signed. |
| 12:58.17 | wpwrak | if it's just signs, maybe some sort of "sign flip" tool could be useful ? |
| 12:58.26 | whitequark | yes, there's one. |
| 12:58.33 | whitequark | enter a negative value for a dimension. |
| 12:58.39 | whitequark | it will flip the sign. |
| 12:59.11 | wpwrak | i was thinking more of something clickable :) show all the things there the sign could be reversed, then experiment |
| 12:59.22 | wpwrak | <PROTECTED> |
| 12:59.25 | whitequark | that's dressing up a bug instead of fixing it |
| 12:59.38 | whitequark | e.g. imagine a hexagon, constrained in the obvious way. say a hex head screw cap |
| 12:59.48 | wpwrak | well, the signs are somewhat arbitrary from a user perspective anyway |
| 12:59.50 | whitequark | now if it's a parametric sketch and you instantiate it with a value 2, it works |
| 13:00.06 | whitequark | if then you re-instantiate it with a value 10, then it's going to get all inside out |
| 13:00.10 | whitequark | and transform into a david's star |
| 13:00.41 | whitequark | the real solution to this is to make solver never flip signs of constraints. right now they are ignored. |
| 13:00.56 | wpwrak | ah yes, that would help a lot |
| 13:01.09 | whitequark | we have actually implemented this, but it didn't work out very well because the old files don't store sign |
| 13:01.19 | whitequark | and breaking backwards compat is a major no |
| 13:01.35 | wpwrak | if there are multiple choices, does it prefer non-self-intersecting solutions over self-intersecting ones, or does that not influence the result ? |
| 13:01.36 | whitequark | so... you know... unit tests... that's how i realized we HAD to have them. |
| 13:01.40 | whitequark | it doesn't care. |
| 13:01.58 | wpwrak | might be another useful guide |
| 13:02.02 | whitequark | the solver is wholly unaware that geometry exists, it solves a system of linear equations, in the straightforward way |
| 13:02.12 | whitequark | moreover, it does not find more than one solution, ever |
| 13:02.21 | whitequark | and it cannot, not with the method of solving we're using |
| 13:02.44 | whitequark | so searching for a non-intersecting geometry, unless it can be straightforwardly expressed as more equations, isn't going to work |
| 13:03.23 | wpwrak | hmm, and it's probably too slow to just do this by trying combinations |
| 13:03.27 | whitequark | yes. |
| 13:03.46 | whitequark | and it's not like it has combinations, the space easily has a massive amount of dimensions |
| 13:04.03 | whitequark | I'm pretty sure one can write a PhD or two on the topic |
| 13:04.18 | wpwrak | well, you could first find all the signs that can be tweaked, then try +++++. ++++-, etc. |
| 13:04.31 | whitequark | better just avoid the sign problem entirely. |
| 13:04.32 | wpwrak | but, combinatory explosion |
| 13:04.43 | whitequark | yes. that's unviable. |
| 13:05.04 | whitequark | it's already slow as it is, without even adding this sort of complexity |
| 13:05.06 | wpwrak | you could probably come up with very clever heuristics that keep the number of guesses low :) |
| 13:05.17 | whitequark | I don't see a point. |
| 13:05.28 | whitequark | like I said, the solution is to avoid the bug entirely, not dressing it up. |
| 13:06.24 | wpwrak | i.e., based on the assumption that people will tend to intervene when the design moves in an unintended direction. so it would usually be just the last one or two edits that may have had an unintended interpretation. |
| 13:06.34 | wpwrak | but yes, if you can avoid it nicely, even better |
| 13:07.05 | whitequark | (gui integration tests) there are currently 0 tests in the solvespace codebase |
| 13:07.22 | whitequark | and testing geometry without rendering it is orders of magnitude harder even |
| 13:07.49 | whitequark | but more importantly, it doesn't actually test that e.g. it can be created, that dragging stuff around doesn't cause crashes, that the menus and links in text window work... |
| 13:07.58 | wpwrak | (compatibility) you could just use the old interpretation and store a (* 1, * -1) flag for newer designs. it have a global format version somewhere ;-) |
| 13:08.22 | whitequark | there's a small part of the geometric core exposed as a library but it doesn't have NURBS booleans, meshes, etc, etc |
| 13:08.29 | whitequark | doesn't even have groups, IIRC |
| 13:09.03 | whitequark | just the solver within a single group. so that's not very useful. and similarly it doesn't know how to load things, and cannot be easily taught to, for complicated reasons |
| 13:09.30 | whitequark | i decided to go with integration tests based on rendering first, and perhaps once i have a proper API and Python or Lua bindings, test it directly using that API |
| 13:10.06 | whitequark | since the API is much more work, this will allow me to iterate on other things that have a high bug introducing potential earlier |
| 13:10.11 | wpwrak | yeah, tricky. but i guess you could test anything 2D by just driving the underlying engine. it often helps to split a complex testing problem into different tests of subsystems. so one would just look at a bunch of numbers, another at a sceenshot, etc. |
| 13:10.35 | whitequark | yes, you can test most of the things within a single group using the exposed core |
| 13:11.04 | wpwrak | also, your tests don't need to be exact. i.e., you could let them pass if, say, 1% of pixels are off. or whatever metric you find useful. such tests would still alert you if there's a major screw-up. |
| 13:11.08 | whitequark | that's not where most bugs are created though, since that part of code is quite robust and also I basically never change them |
| 13:11.30 | whitequark | "1% of pixels" is a poor metric. an error message can well be under 1% of red pixels |
| 13:11.57 | whitequark | moreover, if I accidentally introduce a floating point instability or something like that, I absolutely do want to be alerted. it ought to be deterministic. |
| 13:12.01 | wpwrak | print errors to stderr and check them separately :) |
| 13:12.15 | whitequark | that's just piling more hacks on already bad code. |
| 13:12.36 | wpwrak | yes, but the floating point problem would show up on the numerical tests. unless you hit something that breaks opengl |
| 13:12.49 | wpwrak | divide and conquer ;-) |
| 13:13.04 | whitequark | the numerical tests do not cover most of the code |
| 13:13.16 | whitequark | most of the code in solvespace deals with meshes, NURBS, and drawing sketches |
| 13:13.23 | whitequark | as well as loading and saving various files |
| 13:13.45 | whitequark | I'm actually not concerned about testing the geometric core because it's very simple and I don't think I've *ever* introduced a problem into it |
| 13:14.30 | whitequark | but e.g. drawing constraints? that's a thousand lines of extremely complicated control flow that depends on many factors like scale, font size, exact positioning, camera angle... |
| 13:14.52 | whitequark | generating meshes is a whole separate can of worms still |
| 13:15.02 | wpwrak | that should be easy: have known input, load, then save, compare the results. if the match in content, use the saves one as your input. add a bit of epsilon so that you don't end up chasing your own tail. |
| 13:15.48 | whitequark | yes. roundtrip testing is exactly what i'm going to do, both with savefiles and on-screen rendering contents |
| 13:15.55 | wpwrak | drawing constraints may be tricky. also because there may be many correct answers |
| 13:16.00 | whitequark | except no epsilon, because again, that's just setting yourself out for failure. |
| 13:16.30 | wpwrak | but i guess there's only so much you can do. if you're unlucky, a minor tweak will invalidate most of your tests, even though the result is still correct, just in a different way |
| 13:16.34 | whitequark | if it doesn't match, then there is a reason, and you better find and fix it. knowing why that happened is even more important than actually fixing the problem. |
| 13:16.45 | whitequark | well... it's not quite that dramatic. |
| 13:17.03 | whitequark | i'll export the rendered results in a way that allows quick visual compare. (a/b slider, if you've seen the one on github) |
| 13:17.23 | whitequark | so once you're done with that, you can quickly go through the tests and "approve" (really just git add) them |
| 13:17.37 | wpwrak | (no epsilon) if save->load->save naturally converges, even better |
| 13:17.45 | whitequark | it shouldn't change. |
| 13:18.14 | whitequark | well. the only reason for nondeterminism i see is ieee754 error, but for that we don't save with the *entire* double precision, i think there are 6 significant digits or so |
| 13:18.21 | whitequark | and if there's an error within those, things are bad |
| 13:18.40 | wpwrak | (visual compare) yup, never underestimate the computing power of that piece of wetware ;-) |
| 13:19.15 | whitequark | there's also testing the text window itself... |
| 13:19.33 | wpwrak | dump as ascii ? :) |
| 13:19.35 | whitequark | it uses a printf-like facility right now, with every piece of styling set up using vt52-like escape codes |
| 13:19.46 | wpwrak | could it get any easier ? ;-) |
| 13:19.50 | whitequark | which is absolutely unmaintainable, among other things |
| 13:20.20 | whitequark | well. no. comparing to known text result isn't especially interesting |
| 13:20.32 | whitequark | what *is* interesting is driving the UI tests through the parts where one clicks on a link. |
| 13:20.54 | whitequark | this is internally done by printf'ing a function pointer, which is then magically recorded inside the "framebuffer" |
| 13:21.05 | wpwrak | neat ;) |
| 13:21.17 | whitequark | "neat" is not the word I'd use |
| 13:21.41 | wpwrak | just run it under valgrind every now and then :) |
| 13:21.52 | whitequark | for one, it requires lots of completely unnecessary global state, because pointers to members aren't compatible with C function pointers |
| 13:22.01 | whitequark | and so all the callbacks have to be static |
| 13:22.13 | whitequark | (in the C++ sense, that is, nonmembers, with no access to member data) |
| 13:22.31 | whitequark | for another, this is making testing really hard |
| 13:22.42 | whitequark | like, I cannot use the link name, because there are often many links with the same name |
| 13:22.51 | whitequark | and using link position in absolute coordinates makes tests very fragile |
| 13:23.09 | wpwrak | name + #occurrence ? |
| 13:23.26 | whitequark | that's not an especially bad solution, although it still is fragile |
| 13:23.36 | whitequark | e.g. think of the configuration screen with lots of [edit] |
| 13:23.48 | wpwrak | iterative search: patter/pattern/pattern/name |
| 13:23.51 | whitequark | do I edit fifty tests every time I add a field? |
| 13:24.00 | whitequark | bleh |
| 13:24.17 | whitequark | worst of all, this design of the text window makes internationalization wholly impossible |
| 13:24.32 | whitequark | even if I fed the input of every printf into gettext, no translator is able to make sense of it |
| 13:25.06 | wpwrak | sed 's/edit/editieren/g;s/save/sichern/g; ...' |
| 13:25.13 | whitequark | very funny. |
| 13:25.41 | wpwrak | use pictograms instead of words :) |
| 13:26.03 | whitequark | well, what i'm going to do with the text window is, most likely, add some sort of templating system |
| 13:26.16 | whitequark | not unlike a backend of a website, except without the "web" part |
| 13:26.37 | wpwrak | unleash the inner artist ! once you're comfortable with the approach, you can move to truly abstract stuff the experts will try to interpret for decades :) |
| 13:26.39 | whitequark | and then I have a clean interface that I can rather easily test |
| 13:27.01 | wpwrak | sounds reasonable |
| 13:27.09 | whitequark | even better, I never have to encipher styling into the baroque vt52-but-not-really codes again |
| 13:27.15 | whitequark | I am *so* looking forward to that |
| 13:27.24 | wpwrak | you could always use <xml> :) |
| 13:27.35 | whitequark | I've considered just embedding a web browser there. |
| 13:27.35 | wpwrak | though vt52 is nicely retro |
| 13:27.58 | whitequark | it's not actually related to vt52 in any way, it just uses escape sequences that set colors, etc |
| 13:28.01 | wpwrak | next step: have sub-screens for ascii-art that is then converted to pixmaps :) |
| 13:28.10 | whitequark | I find actual vt52 escape codes *far* more readable than this system |
| 13:28.17 | whitequark | which is... an impressive achievement |
| 13:30.06 | whitequark | (web browser) but then I looked at the size of such a dependency, and then I realized that not using gtk or qt on Windows means using the engine of MSIE |
| 13:30.10 | whitequark | and then I reconsidered. |
| 13:30.28 | whitequark | because it's actually not at all hard to make a minimal layout system that just does the 3.5 things the existing text window needs. |
| 13:31.09 | whitequark | there's also The Language Not To Be Named Which Makes It Impossible To Center Things Vertically |
| 13:32.59 | wpwrak | hmm, not sure if i met that one |
| 13:33.08 | whitequark | CSS :) |
| 13:33.41 | whitequark | meaning, if I used HTML+CSS, then for many things the text window currently uses I'd have to use a specific combination of HTML and CSS patterns to achieve the desired look |
| 13:33.55 | whitequark | this just makes it harder and harder to maintain a consistent look and feel |
| 13:34.04 | whitequark | the editor/color picker would have to become javascript... meh |
| 13:34.25 | wpwrak | ah yes, css definitely puts a lot of complexity into things |
| 13:35.10 | whitequark | like, I know web dev, I did it commercially for many years |
| 13:35.18 | whitequark | which is exactly why /I do not want to add webdev here/ |
| 13:35.46 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 13:37.43 | whitequark | honestly the thing that surprises me most is people who did webdev for years who want other things to be more like webdev |
| 13:38.17 | wpwrak | if you're a hammer, you want everything to look like a nail :) |
| 13:39.03 | whitequark | what if you're a hammer with a massive migraine |
| 13:42.50 | wpwrak | that's part of the job description :) |
| 14:06.20 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |
| 14:37.34 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 15:10.51 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 15:12.21 | *** join/#qi-hardware wpwrak (~werner@22-207-231-201.fibertel.com.ar) |
| 15:39.08 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 16:40.42 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 17:42.18 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 18:00.42 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 18:36.59 | whitequark | hmmmm https://www.washingtonpost.com/news/wonk/wp/2015/07/23/call-off-the-bee-pocalypse-u-s-honeybee-colonies-hit-a-20-year-high/ |
| 18:37.46 | larsc | but 48% of them died this winter |
| 19:02.16 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 19:52.28 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |
| 20:03.14 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 21:04.10 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |
| 21:04.25 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 21:41.13 | *** join/#qi-hardware doomlord (~textual@host86-152-129-204.range86-152.btcentralplus.com) |
| 21:43.01 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |
| 21:50.59 | *** join/#qi-hardware doomlord (~textual@host86-152-129-204.range86-152.btcentralplus.com) |
| 22:05.19 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 22:11.31 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |
| 22:18.59 | *** join/#qi-hardware MistahDarcy (~crash@71-80-254-214.dhcp.rvsd.ca.charter.com) |
| 22:18.59 | *** join/#qi-hardware MistahDarcy (~crash@fsf/member/MistahDarcy) |
| 22:30.51 | *** join/#qi-hardware doomlord (~textual@host86-152-129-204.range86-152.btcentralplus.com) |
| 23:06.53 | *** join/#qi-hardware fengling (~fengling@58.135.95.134) |
| 23:12.57 | *** join/#qi-hardware doomlord (~textual@host86-152-129-204.range86-152.btcentralplus.com) |
| 23:34.26 | *** join/#qi-hardware mth (~mth@82-168-135-203.ip.open.net) |